System and method for remote emissions control unit monitoring and reprogramming

ABSTRACT

Disclosed are methods, systems, and apparatus for remote reprogramming of an automotive controller and determining and reporting vehicle carbon emissions using a local device, a client device, a technician device and a system server. The local device is connected to the automotive controller and is wirelessly connected to the client device. The client device is connected to the technician device through a system server. Programming configurations, including firmware, settings, and parameter updates, are selected from a technician device, sent to the system server, and uploaded to local device using J2534 communication protocol. The client device receives the fuel consumption data from the local device and sends the data to the system server. The system server determines the carbon emissions based on the fuel consumption and reports the emissions to a third-party to certify carbon offset.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. Application No. 17/646,077filed Dec. 27, 2021, now U.S. Pat. No. 11,670,119 granted on Jun. 6,2023, which is a continuation of U.S. Application No. 16/824,256 filedMar. 19, 2020, now U.S. Pat. No. 11,210,871 granted Dec. 28, 2021, whichis a continuation-in-part of U.S. Application No. 16/805,454 filed Feb.28, 2020, now U.S. Pat. No. 11,430,273 granted on Aug. 30, 2022, whichis a continuation-in-part of U.S. Application No. 16/673,907 filed Nov.4, 2019, now U.S. Pat. No. 11,210,874 granted Dec. 28, 2021, which is acontinuation-in-part of U.S. Application No. 16/673,873 filed Nov. 4,2019, now U.S. Pat. No. 11,119,757 granted Sep. 14, 2021, which is acontinuation-in-part of U.S. Application No. 16/049,670 filed Jul. 30,2018, now U.S. Pat. No. 10,614,640 granted Apr. 7, 2020, which is acontinuation-in-part of U.S. Application No. 15/884,246 filed Jan. 30,2018, now U.S. Pat. No. 10,037,633, granted Jul. 31, 2018, which is acontinuation-in-part of U.S. Application No. 15/228,926 filed Aug. 4,2016, now U.S. Pat. No. 10,621,796 granted Apr. 14, 2020, which claimspriority to U.S. Provisional Application No. 62/201,462 filed Aug. 5,2015. Each of the applications listed above is incorporated herein byreference in their entirety.

BACKGROUND OF THE INVENTION

An engine control unit or an “ECU” is a widely used type of electroniccontroller that monitors sensor output and controls a series ofactuators on an internal combustion engine to ensure optimal engineperformance. It does this by reading values of a multitude of sensors inthe vehicle and storing and interpreting the data it receives using datastructures, such as lookup tables. These lookup tables may be used tomonitor the accuracy of the sensors or to adjust engine actuatorsappropriately.

The ECU monitors various sensors on the automobile such as the odometerand sensors for oxygen level, coolant temperature, mass air flow, airintake temperature, crank shaft angle, throttle position, cam shaftangle, and engine knock. Communicated packets include information fromthe odometer, while lookup tables provide feedback information foradjustment and control of ignition timing, cam shaft position, fuelinjector input, fuel pump input, fuel pump pressure, cooling fan speed,admission control systems, forced air induction controls, tractioncontrols, and transmission gear selections. In many situations, ECUsalso send error codes to the vehicle dashboard to indicate immediateproblems, such as overheating, or maintenance requirements, like oilchanges. In some cases, the error codes activate warning lights whichare deactivated after repair.

Certain classes of ECUs are programmable. Modern ECUs incorporate amicroprocessor which can process inputs from engine sensors in realtime. The microprocessor stores its programming in memory or e-promsattached to the CPU of the microprocessor.

Programmable ECUs are used, for example, where significant aftermarketperformance enhancing modifications have been made. Such modificationsoften include the addition of a turbo charger, intercooler or modifiedexhaust system. Programmable ECU’s are also used for several vehiclesystems, such as engine control module (ECM), transmission controlmodule (TCM), body control module, anti-lock brake system (ABS), airbagcontrol module, and so on, that each receive routine updates from themanufacturer of the vehicle. Each ECU is remapped or reprogrammed toadapt the performance of the involved system to match the requiredmodifications and/or to update the software and parameters of the ECU.Other changes for high performance engines which can be remapped orreprogrammed in an ECU include ignition position, timing, RPM, coolanttemperature, transient fueling, low fuel pressure modifiers and a closedloop lambda (in order to modify a target air/fuel ratio), turbo chargerwaste gate control, staged fuel injection, variable cam timing, gearcontrol, and turbo charger anti-lag.

The ECU may be integrated and synchronized with one or more additionalelectronic devices to perform one or more additional functions. One suchdevice is the electronic logging device (ELD), which may be usedtogether with the ECU to record driving time, for easier, more accuratehours of service (HOS) recording.

Vehicle manufacturers utilize a number of different communicationsprotocols for diagnosing and reprograming a vehicle’s ECU. Until recentyears a different diagnostic/service device was required for eachcommunication protocol. As a result, third-party automotive technicianswould either need to have a device for every communication protocol inorder to service all vehicles, or turn away clientele. In 2002 theSociety of Automotive Engineers (SAE) developed the J2534 standard in aneffort to standardize aftermarket emissions related services, and complywith EPA, California Air Resources Board (CARB) mandates geared towardsreducing harmful emissions.

The SAE J2534 standard allows for aftermarket flash re-programming ofemissions related modules (ECM/TCM). J2534 standard requires a compliantJ2534 hardware device with SAE J1962 OBDII connector, J2534 Applicationand DLL file, and a J2534 compliant OEM API. The standard utilizes anumber of universal communication functions that allow a computer tocommunicate with any vehicle ECU regardless of the communicationsprotocol used by the vehicle, such as: PassThruConnect;PassThruDisconnect; PassThruReadMsgs; PassThruWriteMsgs;PassThruStartPeriodicMsg; PassThruStopPeriodicMsg;PassThruStartMsgFilter; PassThruStopMsgFilter; PassThuSetProgrammingVoltage; PassThruReadVersion; PassThruGetLastError; and PassThruloctl.The communication protocols supported by the J2534 standard are;ISO9141, ISO14230 (KWP2000), J1850, CAN (ISO11898), ISO15765, SAE J2610,and J1939.

The EPA, CARB and a number of other environmental agencies encourage thereduction of carbon emissions by changing population behavior. Forexample, activities such as walking, biking, driving fuel efficient orelectric vehicles, and keeping tires inflated are encouraged. Analternative means of reducing carbon emissions is participation in acarbon offset program. In theory, a carbon offset program balancescarbon emissions by funding renewable energy and energy efficientprojects. For instance, planting trees theoretically offsets vehicleemissions. To encourage participation in carbon emission reduction andoffset programs many local agencies provide incentives in the form oftax reduction. In order to benefit from carbon offsets, carbon emissionsmust be calculated and certified by a third-party agency that meetscertain standards such as, the Quality Assurance Standard (QAS),Verified Carbon Standard (VCS), the Gold Standard Voluntary EmissionReductions (VER), and the Certified Emission Reductions (CER) standard.

Generally, “heavy-duty” vehicles, such as commercial trucks (e.g. 18wheelers, garbage trucks, delivery trucks) and buses, are required tocomply with a larger number of regulations and reporting requirementsthan consumer vehicles. For instance, as part of the Cleaner TrucksInitiative, the EPA regulates heavy-duty vehicles in an effort to reducecarbon emissions. Generally, these vehicles tend to operate on dieselengines, however other gasoline or spark ignition vehicles are regulatedas well. The EPA regulates all vehicles with a gross vehicle weight over14,000 pounds, and certain vehicles with a gross vehicle weight between8,500 and 14,000 pounds. A vehicle’s ECU and emissions control systemmust meet certain functional and operational requirements to becompliant with EPA regulations. As yet another example, the FederalMotor Carrier Safety Administration (FMCSA) has strict regulations whichrequire heavy-duty vehicles to utilize an electronic logging device(ELD) to logs hours of service (HOS). These logs, or records of duty(RODs) must be accessible during any safety audit, and reported to motorcarriers for every 24-hour period.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a system diagram of a cloud based automotive techniciansystem.

FIG. 2A is a sequence diagram of a method for updating parameters on anautomotive controller.

FIG. 2B is a sequence diagram of a method for interaction with anautomotive controller and a client device.

FIG. 2C is a sequence diagram of a method for interaction with a localdevice and a client device.

FIG. 3 is a block diagram of a cloud based automotive technician system.

FIGS. 4A and 4B are a sequence diagrams of a method for updating anautomotive controller based on data from the automotive controller.

FIG. 5A is a diagram of a user interface of a preferred embodiment for amultiple gauge view with eight gauges.

FIG. 5B is a diagram of a user interface of a preferred embodiment fordragging and dropping a gauge.

FIGS. 6A, 6B, and 6C are diagrams of a user interface of a preferredembodiment for a multiple gauge view with four sliding gauges.

FIGS. 7A, 7B, and 7C are diagrams of a user interface of a preferredembodiment for selecting a gauge.

FIGS. 8A and 8B are diagrams of a user interface of a preferredembodiment for selecting a first gauge style.

FIGS. 9A and 9B are diagrams of a user interface of a preferredembodiment for selecting a second gauge style.

FIGS. 10A and 10B are diagrams of a user interface of a preferredembodiment for selecting a third gauge style.

FIGS. 11A and 11B are diagrams of a user interface of a preferredembodiment for selecting a fourth gauge style.

FIGS. 12A, 12B, 12C, 12D, 12E, 12F, 12G, 12H and 12I are diagrams of auser interface of a preferred embodiment for adjusting parameters.

FIGS. 13A and 13B are diagrams of a user interface of a preferredembodiment for selecting units of a gauge.

FIGS. 14A, 14B, 14C, 14D and 14E are diagrams of a user interface of apreferred embodiment for a multiple gauge view with five gauges.

FIGS. 15A, 15B, 15C and 15D are diagrams of a user interface of apreferred embodiment for selecting gauges for a multiple gauge view.

FIGS. 16A, 16B, 16C, 16D and 16E are diagrams of a user interface of apreferred embodiment for vehicle management.

FIGS. 17A, 17B and 17C are diagrams of a user interface of a preferredembodiment for displaying diagnostics.

FIGS. 18A and 18B are diagrams of a user interface of a preferredembodiment for data log management.

FIGS. 19A, 19B, 19C and 19D are diagrams of a user interface of apreferred embodiment for settings management.

FIGS. 20A, 20B, 20C and 20D are diagrams of databases and records of apreferred embodiment.

FIG. 21 is a block diagram of a local device of a preferred embodiment.

FIGS. 22-1 – 22–2 is a diagram of a system for cloud based technicianaccess to vehicle data.

FIGS. 23A, 23B, 23C, 23D-1 – 23D-2, 23E, 23F-1 – 23F-2 and 23G-1 – 23G-2is a sequence diagram of a method for cloud based technician access tovehicle data.

FIGS. 24A, 24B, 24C and 24D are diagrams of a user interface fordisplaying vehicle data on a client device.

FIGS. 25A, 25B, 25C and 25D are diagrams of a user interface fordisplaying vehicle data in a graph on a client device.

FIG. 26 is diagram of a user interface for cloud based display ofvehicle data in a graph on a client device.

FIGS. 27A, 27B, 27C, 27D, 27E, 27F, 27G, 27H, 27I, 27J and 27K arediagrams of user interfaces for cloud based updates to ECU profiles.

FIG. 28 is a schematic of a local device that connects to a mobilenetwork.

FIG. 29 is a state diagram of a preferred embodiment.

FIGS. 30A, 30B, 30C and 30D are flowcharts for a mode select state of apreferred embodiment.

FIG. 31 is a flowchart of an output control mode state of a preferredembodiment.

FIG. 32 is a network flow diagram of an ELD state of a preferredembodiment.

FIGS. 33A, 33B, 33C, 33D and 33E are diagrams of graphic user interfacesof a preferred embodiment.

FIG. 34 is a flowchart of a method of generating a certified log of apreferred embodiment.

FIG. 35 is a network flow diagram of a third-party proxy mode of apreferred embodiment.

FIG. 36 is a network flow diagram of a system for updating software.

FIGS. 37-1 - 37-2 is a network flow diagram for a method for interactionwith various system nodes to enable J2534 compliance.

FIG. 38 is a network flow diagram of a system for updating software.

FIG. 39 is a sequence diagram of a method of updating a techniciandevice.

FIGS. 40A-1 - 40A-8 is a network flow diagram of a system for updatingan automotive controller in a preferred embodiment.

FIG. 40B is a method diagram of a communications system for updating anautomotive controller in a preferred embodiment.

FIG. 41A is a screenshot of a user interface for cloud based techniciancommunication with client device.

FIGS. 41B and 41C are screenshots of a user interface for cloud basedtechnician access to vehicle data and software updates.

FIG. 42 is a screenshot of a user interface for cloud basedadministrator access to upload software of a preferred embodiment.

FIGS. 43A, 43B, 43C and 43D are screenshots of a user interface for apreferred embodiment of a system for updating an automotive controller.

FIGS. 44A, 44B, 44C, 44D and 44E are screenshots of a technician userinterface of a preferred embodiment.

FIGS. 45-1 - 45-3 is a network flow diagram of a system for determiningand certifying carbon offsets.

FIG. 46 is a system diagram of a vehicle display network.

FIG. 47 is a schematic of a display device that is connected to a localdevice. device.

FIG. 48 is a sequence diagram of a method for interaction between anautomotive controller and a display.

FIG. 49 is a diagram of a display device showing a user interfacedisplaying vehicle data.

FIG. 50 is a system diagram of a fleet management system for monitoringa vehicle device.

FIGS. 51A-1 - 51A-2 is a sequence diagram of a method for enablingelectronic logging of vehicle and driver data from a display device.

FIGS. 51B-1 - 51B-2 is a sequence diagram of a method for enablingelectronic logging of vehicle and driver data from a client device.

FIG. 51C is a sequence diagram of a method for providing third-partyaccess to vehicle and driver data.

FIGS. 51D-1 - 51D-2 is a sequence diagram of a method for remote fleetmanagement vehicle and driver data.

FIGS. 51E-1 - 51E-3 is a sequence diagram of a method for providingremote technician access to vehicle and driver data.

DETAILED DESCRIPTION OF THE INVENTION

Referring to FIG. 1 , system 100 is provided. System 100 includes systemserver 102 connected to internet 108 through web server 104. The systemserver also includes database 106.

Client device 110 is connected through a mobile network to internet 108and contains application 111. Client device 110 is also connected tolocal device 112. Local device 112 is a J2534 compliant hardware deviceand can be fitted with a SAE J1962 OBDII connector. In a preferredembodiment the local device establishes a Wi-Fi or Bluetooth connectionbetween the client device and the automobile. Local device 112 ishardwired to an automotive controller, such as vehicle device 114.Vehicle device 114 is connected to sensors 120 and actuators 122resident on the vehicle. The sensors and actuators communicate with theonboard controller through a CAN BUS (also known as a controller areanetwork (CAN) bus) as is known in the art.

Client device 110, acts as a client of system server 102, and as aclient of local device 112. Embodiments of client device 110 include anyhandheld wireless device, such as, a smart phone, a tablet computer, anotebook computer, a netbook computer, and so on.

Technician device 124 and third-party device 130 are connected tointernet 108 and communicate through the internet to system server 102,and dealer device 116. Technician device 124 contains J2534 application126 and OEM API 128. Third-party device 130 contains J2534 application132, and OEM API 134. Embodiments of OEM API 128 and 134 include a J2534compliant vehicle manufacturer application program for the analysis andreprogramming of vehicle device 114. J2534 application 126 and 132include a J2534 DLL file with J2534 compliant functions and routines forcommunication between local device 112 and client device 110, techniciandevice 124, and third-party device 130.

Dealer device 116 is also connected to internet 108 and communicatesthrough the internet to technician device 124 and third-party device130. Dealer device 116 is contains database 117. In a preferredembodiment dealer device 116 stores application files for OEM API 128and 134. Similarly, calibration writer server 118 is connected throughthe internet to system server 102 and client device 110.

Referring to FIG. 2A, operation of a preferred embodiment 200 will bedescribed. In use, the device allows recording and viewing of automobileinformation, diagnostics, automobile updates for onboard computers, anddata logging to allow study of driving habits to research fuel economy.

At step 201, the client device opens the application and sets up anaccount by entering certain demographic information. At step 202, theapplication uploads the account information to system server 102.

At step 203, the calibration writer server sets up an account through aform served up through the internet from the system server. Thecalibration writer server includes account information such as name,address, email address, and submit computer Cal/Pid. At step 204,calibration writer server inputs a set of operating system parameterswhich include programming information and look up tables for the onboardcontroller. At step 206, the parameters are submitted to system server102. At step 208, system server 102 stores the parameters and theaccount implementation. At step 210, the database is updated by thesystem server with the new parameters and associated with thecalibration writer server. At step 212, the system server uploads theparameters to client device 110 via a wireless network.

In an alternative embodiment, a technician downloads the parameters orfirmware from calibration writer server 118 via a web browser. Thetechnician then uses system server 102 to download the updatedparameters or firmware to client device 110.

At step 214, a client device stores the parameters. At step 215, clientdevice opens an application (or “App”) which displays the parameters andcertain options to the user. At step 216, the client device receivesoptions from the user as to which parameters to implement. At step 218,the chosen parameters are uploaded to the local device via a Wi-Fi orBluetooth connection. At step 220, the local device stores theparameters and initiates certain timing functions such as onboardrecording and storage of data.

At step 222, the chosen parameters are uploaded to the vehicle device.Step 222, may further include local device 112 using Socket_CAN, or anopen source driver and network stack that is compatible with the vehicledevice. For example, vehicle device 114 may be configured to use acommunication protocol including, but not limited to, SAE J/1979, SAE2190, ISO-14230-3, ISO-14229.2006, a CAN protocol, and combinationsthereof. Local device 112 is configured to receive communications in afirst communication protocol (e.g., JavaScript Object Notation JSONmessage), and then forward them, or data from them, in the propercommunication protocol for vehicle device 114.

At step 224, the vehicle device stores the new parameters and lookuptables. At step 226 the vehicle device implements the new parameters andlookup tables. Step 226 further includes reprogramming or remapping thefirmware of the vehicle using a bootfile. Step 226 may also include acheck to see if previous updates or programming operations failed. Ifthe updates or operations failed, then a reflash recovery operation isperformed. The reflash recovery operation may include sending orre-sending a seed or key for a diagnostics login, getting the failedupdate file, reading data from the file, downloading a bootfile, erasinga sector, downloading sector data to the appropriate module (e.g., ECM),iterating the erasing and downloading of sector data for multiplesectors of the appropriate module, and resetting the module. Uponcompletion of the reflash recovery operation, the downloading of the newconfiguration file and installing of the customer modificationsproceeds.

At step 228, the vehicle device generates an acknowledge signal. At step230, the acknowledge signal is sent to the local device. At step 231,the local device stores the acknowledge signal. At step 232, the localdevice reports the acknowledge signal to client device 110 via the WiFior Bluetooth connection. At step 233, the client device stores theacknowledge signal and the App displays the status of the local deviceand the uploaded parameters.

Referring to FIG. 2B, an alternate preferred embodiment 238 isdescribed. At step 243, the client device requests a target for a feedof live data from the vehicle device. Step 244, the client devicetransmits the upload request to the local device. At step 245, the localdevice stores live data request. At step 248, the local device sends arequest for live data to vehicle device 114. At step 250, the vehicledevice uploads the system status from the automobile to the localdevice. At step 252, the system status is sent to the local device. Atstep 256, the local device stores the system status. At step 258, thelocal device uploads the system status to client device 110. At step260, client device stores the system status. At step 261, the localdevice enters a loop to repeatedly request system status (“live data”)from the vehicle device. At step 262, the App displays the systemstatus. The display is refreshed as updated system status is receivedfrom the local device.

At step 263, client device 110 chooses an option on the application toclear error codes. At step 264, the request is uploaded to the localdevice. At step 265, the request is stored in memory on the localdevice. At step 266, the request is uploaded to the vehicle device. Atstep 267, the vehicle device acknowledges the request and clears theerror code.

At step 268, the client device chooses an option on the application torequest a diagnostic report. At step 269, the request is uploaded to thelocal device. At step 270, the local device stores the request. At step271, the local device uploads the request to the vehicle device. At step272, the vehicle device generates the diagnostic report. At step 273,the diagnostic report is sent to the local device. At step 274, thelocal device stores the diagnostic report, according to date and time,in memory. At step 275, the diagnostic report is sent to the clientdevice. At step 276, the diagnostic report is displayed according to therequest of the user.

At step 277, the client device, through use of the application requestsa calibration report. At step 278, the calibration request is uploadedto the local device. At step 279, the local device stores the requestfor calibration. At step 280, the local device forwards the request tothe vehicle device. At step 281, the vehicle device accesses thecurrently stored parameters and the calibration. At step 282, theparameters are sent to the local device. At step 283, the local devicestores the current set of parameters according a date and time stamp. Atstep 284, the local device sends the parameters to the client device. Atstep 285, the application on the client device displays the requestedcalibration parameters.

Referring to FIG. 2C, a third embodiment 286 is described. At step 287,client device 110 generates a period request. A period request is arequest for a feed of logged data from the vehicle device for aspecified period of time via local device 112. The period request forthe logged data may be generated from customer client device 110. Atstep 288, the client device transmits the period request to local device112. At step 289, local device 112 gathers logged data stored on thedevice sufficient to fulfill the amount of logged data required for theperiod request. At step 290, the local device performs a logged datatransfer to client device 110.

At step 292, the client device stores and displays the logged data.

Referring to FIG. 3 , a schematic map 300 of the setup of system server102 and certain functions of a preferred embodiment will be described.

System server 102 presents a set of webpages for the various users ofthe system through web server 104 using a user/password interface. At302, 304, and 306 a schematic of the local home page is shown. Localhome page provides options for a choice of a user type for each ofcalibration writer server, a dealer, and a customer or “end user.” Thedatabase includes records for each vehicle 310 and each computer profileID number 312. Each vehicle 310 includes vehicle identification number,ECU serial number, make, model, engine, fuel tank number, gear ratio,tire size and vehicle modification categories. Each record is associatedwith a particular vehicle entered into the system. Computer profile IDnumber 312 is a database entry including vehicle, calibration, PIDconfiguration, and warning type. Computer profile ID number 312 alsoincludes vehicle options and datalog recordings for each vehicle.

Calibration writers webpage 304 includes forms for entry of a datarecord for users who input engine control parameters. Each data recordincludes entries for photos or logos, name, phone, address, start date,email and computer Cal/Pid. When the form is complete, upon entry,system server 102 enters the data from the data form into a record intothe database (e.g., logged data). The system server then copies the datarecord into one or more computer profiles having an ID number.Accordingly, the data records are associated with computer profile IDnumber 312. All reports generated by the automotive controller at therequest of the local device are associated with current calibration ofthe vehicle when stored in memory. In some embodiments, the data in therecord is then copied directly into memory at vehicles 310.

The dealers webpage 306 serves up a form for data entry including datarelated to photo/logo, name, phone, address, start date and emailaddress. The “dealers” in some embodiments are maintenance shops whichservice vehicles but do not write calibrations. In other embodiments,the “dealers” include manufacturers or dealerships that writecalibrations and service vehicles. For example, a customer may taketheir vehicle to a manufacturer or dealership for repairs, and mayalready have access to the web-based application. In this case, themanufacturer or dealership may choose to use, or have the customer use,the web-based application and supply its own calibration files.

The customers webpage 308 includes a form for entry of data includingbut not limited to, photo, phone number, start date and email address.The web form also enables the customer to request download of anapplication to be locally installed. The APP GUI provides access to thefunctions of the local device. In a preferred embodiment, the functionsinclude but are not limited to, requesting a report of a currentcalibration, requesting a live report of engine status, requesting adiagnosis report, requesting that an error code be cleared, uploading acalibration update from a dealer or manufacturer, volume control, andcombinations thereof.

The APP GUI also allows for vehicle modifications. The vehiclemodifications may include one or more of: tuning parameters (i.e., atune) for the vehicle; firmware updates for the vehicle; live vehicledata as received by a controller (e.g., vehicle device 114) of thevehicle; logged vehicle data as stored by local device 112, as stored bysystem server 102, or as stored by a database of system server 102;diagnostic reports, trouble codes, and parameter IDs; driver’s recordsof duty (RODS); and combinations thereof. The vehicle modifications maybe communicated using a communication protocol including, but notlimited to, a telematics protocol (e.g., Ethernet, Wi-Fi, Post OfficeProtocol 3 (POP3), Internet Message Access Protocol (IMAP), Simple MailTransfer Protocol (SMTP), Hyper Text Transfer Protocol (HTTP), etc.), ora local protocol (e.g., Bluetooth, USB 2.0, infrared, etc.).

Referring to FIGS. 4A and 4B, method 400 updates engine parameters inresponse to a check engine code (also referred to as a diagnostictrouble code (DTC)) being generated by vehicle device 114. The methodincludes one or more messages passed between calibration writer server118, system server 102, client device 110, local device 112, and vehicledevice 114.

At step 411, vehicle device 114 generates a check engine code andfreezes a frame of data. The check engine code identifies a problem withthe vehicle. The frozen data indicates the status of the vehicle at thetime when the problem that caused the check engine code to be generatedoccurred.

At step 412, a data connection is established between local device 112and vehicle device 114. In one embodiment, the data connection isestablished by connecting local device 112 to an onboard diagnosticsport that is connected to a CAN BUS to which vehicle device 114 isconnected.

At step 413, a wireless connection is established between client device110 and local device 112. In one embodiment, local device 112 acts as awireless local area network (WLAN) access point to which client device110 can connect. In establishing the wireless connection, a transmissioncontrol protocol (TCP) socket is opened between client device 110 andlocal device 112 so that data can be passed back and forth betweenclient device 110 and local device 112 using JSON messages.

At step 414, a request for gauge data is sent from client device 110 andis received by local device 112. In one embodiment, the request is sentusing JSON using the TCP socket. For each of the one or more gaugesdisplayed by client device 110, a gauge data request is sent. Afterreceiving the request from client device 110 by local device 112, clientdevice 110 is subscribed to and receives notifications from local device112 that include updated data to be displayed on the gauge associatedwith the gauge data request.

At step 415, a data request is sent from local device 112 and isreceived by vehicle device 114.

At step 416, vehicle device 114 retrieves the gauge data. In oneembodiment, vehicle device 114 retrieves parameter identifier (PID) datathat is associated with the gauge data.

At step 417, the data is sent from vehicle device 114 and is received bylocal device 112.

Optionally at step 418, local device 112 records the data received fromvehicle device 114 in a log file on local device 112.

At step 419, the requested data is sent from local device 112 and isreceived by client device 110. In one embodiment, client device 110 issubscribed to local device 112 so as to receive a notification fromlocal device 112 each time local device 112 receives updated data fromvehicle device 114.

At step 420, the data is displayed by client device 110. The layoutsettings that describe the “look and feel” of the gauge are stored onclient device 110 and the data is displayed in accordance to the layoutsettings.

At step 421, a request for the engine code, the frozen data, andoptionally the log data is sent from client device 110 and is receivedby local device 112.

At step 422, a request for the engine code and the frozen data is sentfrom local device 112 and is received by vehicle device 114.

At step 423, vehicle device 114 retrieves the engine code and frozendata that were generated in step 411.

At step 424, the engine code and frozen data are sent from vehicledevice 114 and are received by local device 112.

At step 425, the engine code, frozen data, and optional log are sentfrom local device 112 and are received by client device 110.

At step 426, client device 110 stores the engine code, frozen data, andoptional log.

Moving to FIG. 4B, at step 427, client device 110 displays the enginecode.

At step 428, the engine code, frozen data, and optional log data is sentfrom client device 110 and is received by system server 102.

At step 429, a request for updated engine parameters is sent from clientdevice 110 and is received by system server 102.

At step 430, a request for updated engine parameters is sent from systemserver 102 and is received by calibration writer server 118.

At step 431, updated parameters and/or firmware are sent fromcalibration writer server 118, and are received by system server 102.

At step 432, the updated parameters and firmware are sent from systemserver 102 and are received by client device 110.

At step 433, the updated parameters and firmware are stored on clientdevice 110.

At step 434, the technician selects one or more parameters and firmwarewith which to update the vehicle.

At step 435, the selected parameters and firmware are sent from clientdevice 110 and are received by local device 112. One or more parametersand the firmware may be selected to be updated and are sent.

At step 436, reprogramming instructions are sent from local device 112and are received by vehicle device 114. In one embodiment, theinstructions cause vehicle device 114 to be flashed with the updatedfirmware when the firmware is selected to be updated. Additionally,parameters can be changed beyond what was included with the updatedfirmware. The updated firmware may be the latest default firmware fromthe vehicle manufacturer that does not have every parameter tuned forthe specific configuration of the vehicle. In one embodiment, thereprogramming instructions of local device 112 first reflashes vehicledevice 114 with the updated firmware and then updates specific enginetuning parameters.

At step 437, vehicle device 114 updates the firmware and parameters tothe values received from local device 112.

Referring to FIGS. 5A and 5B, user interface 502 includes menu button504 on title bar 506, which is above eight gauge view 508. Eight gaugeview 508 includes eight (8) mini gauge views 510, 512, 514, 516, 518,520, 522, and 524.

User interface 502 is displayed on a client device via an app running onthe client device. The name, value, and units of each respective minigauge views 510, 512, 514, 516, 518, 520, 522, and 524 are displayed onuser interface 502 on a client device. Values 542, 544, 546, 548, 550,552, 554, and 556 respectively of each mini gauge views 510, 512, 514,516, 518, 520, 522, and 524 are continuously updated as new PID valuesare received from the automotive controller. In the embodiment of FIG.5A, ten (10) PIDs are named with the units indicated in the table below.PID values, names, and units may be different for different vehicles andthe table below is merely one example.

TABLE 1 PID Mini Gauge View Name Units 0 510 Engine Coolant TemperatureDegrees Fahrenheit (°F) 1 512 Speed Miles per Hour (MPH) 2 530Revolutions per Minute Revolutions per Minute (RPM) 3 532 BatteryVoltage Voltage (V) 4 518 Transmission Temperature Degrees Fahrenheit(°F) 5 (not shown) Boost Pounds per Square Inch (PSI) 6 522 CalculatedLoad Percent of Max (%) 7 524 Injector Pressure Thousand Pounds perSquare Inch (kPSI) 8 (not shown) Injector Pulse Width Milliseconds (ms)9 520 Throttle Position Sensor Percent of Max (%)

Mini gauge view 510 includes name 526, value 542, and units 558 and isassociated with a PID. Name 526 indicates that mini gauge view 510displays the engine coolant temperature, which value 542 indicates is at156.0, which units 558 indicates are in degrees Fahrenheit. Mini gaugeview 510 is shaded in a green color to indicate that value 542 is withina desired range for the engine coolant temperature.

Mini gauge view 512 includes name 528, value 544, and units 560 and isassociated with a PID. Name 528 indicates that mini gauge view 512displays the speed, which value 544 indicates is at 31.0, which units560 indicates are in miles per hour. Mini gauge view 512 is not shadedgreen, which would indicate that value 544 is in a desired range, and isnot shaded red, which would indicate that value 544 is in a warningrange.

Mini gauge view 514 includes name 530, value 546, and units 562 and isassociated with a PID. Name 530 indicates that mini gauge view 514displays the revolutions per minute (RPM) of the engine, which value 546indicates is at 746, which units 562 indicates are in revolutions perminute. Mini gauge view 514 is not shaded green, which would indicatethat value 546 is in a desired range, and is not shaded red, which wouldindicate that value 546 is in a warning range.

Mini gauge view 516 includes name 532, value 548, and units 564 and isassociated with a PID. Name 532 indicates that mini gauge view 516displays the battery voltage of the engine, which value 548 indicates isat 2.00, which units 564 indicates are in Volts (V). Mini gauge view 516is shaded red to indicate that value 548 is within a warning range forthe battery voltage.

Mini gauge view 518 includes name 534, value 550, and units 566 and isassociated with a PID. Name 534 indicates that mini gauge view 518displays the transmission temperature of the engine, which value 550indicates is at 219.0, which units 566 indicates are in degreesFahrenheit. Mini gauge view 518 is shaded red to indicate that value 550is within a warning range for the transmission temperature.

Mini gauge view 520 includes name 536, value 552, and units 568 and isassociated with a PID. Name 536 indicates that mini gauge view 520displays the throttle position sensor, which value 552 indicates is at35, which units 568 indicates is a percentage value. Mini gauge view 520is not shaded green, which would indicate that value 552 is in a desiredrange, and is not shaded red, which would indicate that value 552 is ina warning range.

Mini gauge view 522 includes name 538, value 554, and units 570 and isassociated with a PID. Name 538 indicates that mini gauge view 522displays the calculated load on the engine, which value 554 indicates isat 35, which units 570 indicates is a percentage value. Mini gauge view522 is not shaded green, which would indicate that value 554 is in adesired range, and is not shaded red, which would indicate that value554 is in a warning range.

Mini gauge view 524 includes name 540, value 556, and units 572 and isassociated with a PID. Name 540 indicates that mini gauge view 524displays the injector pressure of the engine, which value 556 indicatesis at 25.0, which units 572 indicates is in thousand pounds per squareinch (kPSI). Mini gauge view 524 is shaded green to indicate that value556 is in a desired range.

FIG. 5B shows a drag and drop operation used to swap the location of twomini gauges on eight gauge view 508. The location of mini gauge view 514is swapped with the location of mini gauge view 524 within eight gaugeview 508 by dragging mini gauge view 514 from its original locationtowards the original location of mini gauge view 524.

Referring to FIG. 6A, user interface 502 is updated to display fourgauge view 604. Four gauge view 604 includes four (4) mini gauge views(512, 514, 518, and 520) and one selected gauge view 606. Mini gaugeview 514 is updated to have its display be highlighted to indicate thatmini gauge view 514 is associated with, and has the same PID as,selected gauge view 606. User interface 502 transitions from eight gaugeview 508 to four gauge view 604 when mini gauge view 514 is selectedfrom eight gauge view 508 via a touch or click event.

Upper row 608 includes mini gauge views 512 and 514. Lower row 610includes mini gauge views 518 and 520.

Referring to FIG. 6B, upper row 608 is slid or dragged to the left toreveal mini gauge view 516. Any two adjacent mini gauge views 510, 512,514, and 516 can be displayed in upper row 608 by sliding or draggingupper row 608 left or right. During a drag or slide event, up to threemini gauge views may be displayed. After the drag or slide event, twomini gauge views are displayed, which need not include the mini gaugethat has been selected (which in FIG. 6B is mini gauge view 512).

Referring to FIG. 6C, lower row 610 is slid or dragged to the left. Anytwo adjacent mini gauge views 518, 520, 522, and 524 can be displayed inlower row 610 by sliding or dragging lower row 610 left or right. Duringa drag or slide event, up to three mini gauge views may be displayed.After the drag or slide event, two mini gauge views are displayed, whichneed not include the mini gauge that has been selected.

Referring to FIGS. 7A, 7B, and 7C, user interface 502 is manipulated tochange the PID of mini gauge view 514.

At FIG. 7A, four gauge view 604 is displayed on user interface 502. Minigauge view 514 has been selected and selected gauge view 606 is shown onuser interface 502.

At FIG. 7B, selected gauge view is slid or dragged up to reveal secondselected gauge view 706.

At FIG. 7C, mini gauge view 514 is updated to become mini gauge view714. In one embodiment, mini gauge view 714 duplicates the informationfrom mini gauge view 516 so that when mini gauge view 714 is unselectedand user interface 502 transitions back to eight gauge view 508, bothmini gauge view 516 and mini gauge view 714 are displayed and both showthe battery voltage.

Referring to FIGS. 8A and 8B, circular gauge style 802 from settingsview 804 is selected for selected gauge view 606. Settings view 804 ofFIG. 8A is displayed after user interface element 806 is selected fromselected gauge view 606 of FIG. 8B.

Settings view 804 includes name 808 and units 810 that identify the nameand units of the PID that is associated with selected gauge view 606.Settings view 804 includes user interface element 812 that, whenselected, transitions user interface 502 from displaying settings view804 (FIG. 8A) to displaying gauge view 606 (FIG. 8B). With the selectionof circular gauge style 802, circular gauge view 814 will be shown onselected gauge view 606.

On selected gauge view 606, name 816 and units 818 that identify thename and units of the PID that is associated with selected gauge view606. Value 820 indicates the current value of the PID associated withselected gauge view 606. Units 822 indicates the current value of thePID associated with selected gauge view 606. User interface element 824indicates what gear is being reported by the automotive controller asthe current gear of the vehicle.

Circular gauge view 814 includes warning section 826. In one embodiment,warning section 826 is shaded in red and indicates that the RPM level istoo low.

Circular gauge view 814 includes desired section 828. In one embodiment,desired section 828 is shaded in green and indicates that the RPM levelis in a desired operating range for the vehicle.

Referring to FIGS. 9A and 9B, arc gauge style 902 from settings view 804is selected for selected gauge view 606. When arc gauge style 902 isselected, selected gauge view 606 shows arc gauge view 904. Arc gaugeview 904 includes warning section 906. In one embodiment, warningsection 906 is shaded in red and indicates that PID values that arewithin warning section 906 are too low.

Arc gauge view 904 includes desired section 908. In one embodiment,desired section 908 is shaded in green and indicates that PID valuesthat are within desired section 908 are in a preferred range for one ofmaximum torque or horsepower.

Referring to FIGS. 10A and 10B, bar gauge style 1002 from settings view804 is selected for selected gauge view 606. When bar gauge style 1002is selected, selected gauge view 606 shows bar gauge view 1004. Bargauge view 1004 includes warning section 1006. In one embodiment,warning section 1006 is shaded in red and indicates that PID values thatare within warning section 1006 are too low.

Bar gauge view 1004 includes desired section 1008. In one embodiment,desired section 1008 is shaded in green and indicates that PID valuesthat are within desired section 1008 are in a preferred range for one ofmaximum torque or horsepower.

Referring to FIGS. 11A and 11B, line history gauge style 1102 fromsettings view 804 is selected for selected gauge view 606. When linehistory gauge style 1102 is selected, selected gauge view 606 shows linehistory gauge view 1104. Line history gauge view 1104 is a graph thatshows recent values for the selected gauge as a function of time. Therecent values are stored on the client device. Line history gauge view1104 shows the most recent data on the right-hand-side of the chart.

Referring to FIGS. 12A through 12I, user interface 502 comprises fourgauge view 604 with selected gauge view 606. Selected gauge view 606includes warning section 826, desired section 828, and warning section1202 that are each adjustable. Warning section 826 identifies when thePID value is too low and warning section 1202 identifies when the PIDvalue is too high.

To adjust the settings for warning section 826, desired section 828, andwarning section 1202, user interface element 806 is selected to displaysettings view 804 (FIG. 12B) and then user interface element 1204 isselected from settings view 804 to display view 1206 (FIG. 12C) on userinterface 502. View 1206 is also referred to as parameter adjustmentview 1206.

Parameter adjustment view 1206 includes user interface element 1208,user interface element 1210, name 1212, and units 1214

User interface element 1208 is a cancel button that, when selected,undoes changes that were made in parameter adjustment view 1206. Afterselecting user interface element 1208, user interface 502 returns tofour gauge view 604 with settings view 804, as in FIG. 12B.

User interface element 1210 is a button that, when selected, acceptschanges that were made in parameter adjustment view 1206. Afterselecting user interface element 1210, user interface 502 returns tofour gauge view 604 with settings view 804, as in FIG. 12B.

Name 1212 and units 1214 identify the type and units of the PIDinformation that is displayed on view 1206. In one embodiment, name 1212is revolutions per minute (RPM) and units 1214 are RPM.

User interface element 1216 is a checkbox that indicates whether desiredsection 828 is shown on selected gauge view 606. The range of desiredsection 828 is controlled by the range between minimum desired threshold1218 and maximum desired threshold 1220. When the PID value is betweenminimum desired threshold 1218 and maximum desired threshold 1220, thenthe PID value is in a desired or preferred range.

The display of warning section 826 and warning section 1202 arecontrolled by user interface element 1222. The range of the gap betweenwarning section 826 and warning section 1202 is controlled by the rangebetween minimum warning threshold 1224 and maximum warning threshold1226. When the PID value is below minimum warning threshold 1224 orabove maximum warning threshold 1226, then the PID value is in a warningrange that could lead to engine fault, damage, or failure.

User interface element 1228 identifies whether the defuel settings areactive. When the PID value is below minimum defuel threshold 1230 orabove maximum defuel threshold 1232, then the PID value is in a defuelrange where the fuel supply to the engine is reduced in order to protectthe engine.

In one embodiment, the relationships shown below are maintained by thethresholds displayed on parameter adjustment view 1206.

$\begin{matrix}\begin{array}{l}{\text{minimum defuel threshold 1230} \leq} \\\text{minimum warning threshold 1224}\end{array} & \text{­­­Rel.1}\end{matrix}$

$\begin{matrix}{\text{minimum warning threshold 1224} \leq \text{minimum desired threshold 1218}} & \text{­­­Rel.2}\end{matrix}$

$\begin{matrix}\begin{array}{l}{\text{minimum desired threshold 1218} \leq} \\\text{maximum desired threshold 1220}\end{array} & \text{­­­Rel.3}\end{matrix}$

$\begin{matrix}\begin{array}{l}{\text{maximum desired threshold 1220} \leq} \\\text{maximum warning threshold 1226}\end{array} & \text{­­­Rel.4}\end{matrix}$

$\begin{matrix}\begin{array}{l}{\text{minimum warning threshold 1226} \leq} \\\text{maximum defuel threshold 1232}\end{array} & \text{­­­Rel.5}\end{matrix}$

Referring to FIG. 12D, when minimum desired threshold 1218 is dragged tothe left, minimum warning threshold 1224 and minimum defuel threshold1230 may also move to the left so that both minimum warning threshold1224 and minimum defuel threshold 1230 remain less than or equal tominimum desired threshold 1218.

When maximum desired threshold 1220 is dragged to the right, maximumwarning threshold 1226 and maximum defuel threshold 1232 may also moveto the right so that both maximum warning threshold 1226 and maximumdefuel threshold 1232 remain greater than or equal to maximum desiredthreshold 1220.

Referring to FIG. 12E, when minimum warning threshold 1224 is dragged tothe right, minimum desired threshold 1218 may also move to the right sothat minimum desired threshold 1218 remains greater than or equal tominimum warning threshold 1224.

When maximum warning threshold 1226 is dragged to the left, maximumdesired threshold 1220 may also move to the left so that maximum desiredthreshold 1220 remains less than or equal to maximum warning threshold1226.

Referring to FIG. 12F, when minimum warning threshold 1224 is dragged tothe left, minimum defuel threshold 1230 may also move to the left sothat minimum defuel threshold 1230 remains less than or equal to minimumwarning threshold 1224.

When maximum warning threshold 1226 is dragged to the right, maximumdefuel threshold 1232 may also move to the right so that maximum defuelthreshold 1232 remains greater than or equal to maximum warningthreshold 1226.

Referring to FIG. 12G, when minimum defuel threshold 1230 is dragged tothe right, minimum warning threshold 1224 and minimum desired threshold1218 may also move to the right so that both minimum warning threshold1224 and minimum desired threshold 1218 remain greater than or equal tominimum defuel threshold 1230.

When maximum defuel threshold 1232 is dragged to the left, maximumwarning threshold 1226 and maximum desired threshold 1220 may also moveto the left so that both maximum warning threshold 1226 and maximumdesired threshold 1220 remain less than or equal to maximum defuelthreshold 1232.

Referring to FIGS. 12H and 12I, when user interface element (checkbox)1216 is unselected and user interface element (done button) 1210 isselected, then the desired section is not displayed on the selectedgauge view 606, as shown in FIG. 12I.

Referring to FIGS. 13A and 13B, user interface 502 displays four gaugeview 604, mini gauge view 518 has been selected, and settings view 804is displayed. Settings view 804 includes user interface element 1302 anduser interface element 1304.

User interface element 1302 and user interface element 1304 allow forthe selection between different units for the PID values associated withmini gauge view 518. In one embodiment, mini gauge view 518 isassociated with transmission temperature and can be displayed in degreesCelsius (°C) upon the selection of user interface element 1302 or indegrees Fahrenheit (°F) upon the selection of user interface element1304.

Referring to FIGS. 14A through 14E, user interface 502 transitions fromeight gauge view 508 to five gauge view 14101. Five gauge view 14101 mayalso be referred to as view 14101. The transition from eight gauge view508 to five gauge view 14101 occurs when there is a slide or drag eventthat drags eight gauge view 508 up to reveal five gauge view 14101.Additionally, the transition from five gauge view 14101 to eight gaugeview 508 occurs when there is a slide or drag event that drags fivegauge view 14101 down to reveal eight gauge view 508.

Referring to FIG. 14B, five gauge view 14101 includes gauge views 14202,14203, 14204, 14205, and 14206, which may be referred to as large centergauge view 14202, top left gauge view 14203, bottom left gauge view14204, top right gauge view 14205, and bottom right gauge view 14206.

Large center gauge view 14202 includes name 14207, value 14208, units14209, gear 14210, and circular gauge view 14211. Circular gauge view14211 includes lower warning section 14212, desired section 14213, andupper warning section 14214. Large center gauge view 14202 indicatesthat the vehicle is in reverse and that the transmission temperature is274.0° F. and is in a warning range that is above the desired range.

Top left gauge view 14203 includes name 14215, units 14216, value 14217,and arc gauge view 14218. Arc gauge view 14218 includes lower warningsection 14219, desired section 14220, and upper warning section 14221.Top left gauge view 14203 indicates that the RPM of the motor is 4328RPM, which is just above the desired range an in the upper warningrange.

Bottom left gauge view 14204 includes name 14223, units 14224, value14225, and arc gauge view 14226. Arc gauge view 14226 includes lowerwarning section 14227, desired section 14228, and upper warning section14229. Bottom left gauge view 14204 indicates that the battery voltageis 15.00 V and is in the upper warning range.

Top right gauge view 14205 includes name 14230, units 14231, value14232, and arc gauge view 14233. Arc gauge view 14233 includes lowerwarning section 14234, desired section 14235, and upper section 14236.Top right gauge view 14205 indicates that the engine coolant temperatureis 240.0° F. and is in the upper warning section above the desiredlevel.

Bottom right gauge view 14206 includes name 14237, units 14238, value14239, and arc gauge view 14240. Arc gauge view 14240 includes warningsection 14241 that indicates which values are too high. Bottom rightgauge view 14206 indicates that the speed of the vehicle is 299.0 MPHand is in the upper warning range.

The names, units, and values displayed on the gauges in five gauge view14101 are each shaded in red to indicate that each of the values of eachof the gauges is in a warning section

When any one of gauge views 14202, 14203, 14204, 14205, and 14206 areselected from five gauge view 14101, user interface 502 transitions fromdisplaying five gauge view 14101 to small five gauge view 14301 andselected gauge view 14302, shown in FIG. 14C. Small five gauge view14301 may also be referred to as view 14301.

Referring to FIG. 14C, small five gauge view 14301 includes gauge views14303, 14304, 14305, 14306, and 14307, which may be referred to as smallcenter gauge view 14303, top left gauge view 14304, bottom left gaugeview 14305, top right gauge view 14306 and bottom right gauge view14307. Gauge views 14303, 14304, 14305, 14306, and 14307 from small fivegauge view 14301 are associated with the same PIDs as gauge views 14202,14203, 14204, 14205, and 14206 from five gauge view 14101 of FIG. 14Brespectively. The values for gauge views 14303, 14304, 14305, 14306, and14307 are continuously updated to reflect the current state of theengine.

Selected gauge view 14302 of FIG. 14C is similar to selected gauge view606 of FIG. 6 and is associated with small center gauge view 14303.Small center gauge view 14303 includes outline 14308 to indicate thatsmall center gauge view 14303 is the gauge view that is linked to orassociated with selected gauge view 14302 and that large center gaugeview 14202 may have been selected from small five gauge view 14101 ofFIG. 14B.

When user interface element 14309 of FIG. 14C is selected, userinterface 502 transitions from displaying selected gauge view 14302 ofFIG. 14C to displaying settings view 14401 of FIG. 14D. Settings view14401 of FIG. 14D is similar to settings view 804 of FIG. 8 .

Referring to FIG. 14D, degrees Fahrenheit (°F) were originally selectedand displayed on small center gauge view 14303. Upon selection of userinterface element 14310, degrees Celsius (°C) are selected and displayedon small center gauge view 14303.

Referring to FIGS. 15A to 15D, when selected gauge view 14302 is slid ordragged up, second selected gauge view 1502 is revealed. Additionally,small center gauge view 14303 that is associated with transmissiontemperature is updated to second small center gauge view 1504. Secondsmall center gauge view 1504 is a Boost value that is 29.0 pounds persquare inch (PSI).

Upon selection of small top right gauge view 14306 in FIG. 15D, secondselected gauge view 1502 of FIG. 15C is updated to third selected gaugeview 1508 of FIG. 15D, which show the same PID information as small topright gauge view 14306. Small top right gauge view 14306 is updated toinclude outline 1510 and outline 1506 around second small center gaugeview 1504 is removed.

Referring to FIG. 16A, menu button 504 is selected. Eight gauge view 508slides partially to the right and down and is made more transparent toenhance the display of menu 1602. Menu 1602 includes user interfaceelements 1604, 1606, 1608, 1610, 1612, and 1614, which may also bereferred to as “My Gauges” button 1604, “My Vehicles” button 1606,“Program” button 1608, “Diagnostics” button 1610, “Datalog” button 1612,and “Settings” button 1614.

Selecting button 1604 removes menu 1602 and brings back the most recentgauge view, which in FIG. 16A is eight gauge view 508.

Selecting button 1606 removes menu 1602 and transitions user interface502 to view 1616 of FIG. 16B. View 1616 may also be referred to as “MyVehicles” view 1616, includes a user interface element for each vehiclethat has been associated with the client device app. User interfaceelement 1618 includes the year, make, and model of the vehicle andindicates that the local device is attached to the vehicle associatedwith user interface

Upon selecting user interface element 1618, user interface 502transitions to view 1620 of FIG. 16C. View 1620 may also be referred toas “Vehicle Management” view 1620, includes user interface elements 1622and 1624, identifies the number of technicians to which the vehicle hasbeen shared and identifies the current ECU profile.

Upon selecting user interface element 1622, user interface 502transitions to view 1626 of FIG. 16D. View 1626 may also be referred toas “Manage Shares” view 1626, includes user interface element 1628, andlists the technicians to which the vehicle has been shared in one ormore user interface elements. As shown, in FIG. 16D, the vehicle has notbeen shared with any technicians.

Selecting user interface element 1624 brings up a different view (notshown) that allows for the management of ECU profiles. The management ofECU profiles includes: updating one or more parameters within a profileand deleting a profile from the client device.

Upon selecting user interface element 1628, user interface 502transitions to view 1630 of FIG. 16E. View 1630 may also be referred toas “Share Vehicle with Technician” view 1630, includes user interfaceelement 1632, keyboard 1634, and user interface element 1636. Userinterface element 1632 is an edit box that receives a technician’s emailaddress that acts as the login information to access a system server,such as system server 102 of FIG. 1 .

In one embodiment, view 1630 of user interface 502 is displayed on aclient device that is used by a technician that is diagnosing the car toallow the technician to log into the server. Upon selection of the“Done” button on keyboard 1634 or user interface element 1636, theclient device app will attempt to login to the system server andassociated (or share) the vehicle with the technician’s client device.

In an alternative embodiment, view 1630 of user interface 502 isdisplayed on a client device that is used by the owner of the vehiclethat is being diagnosed. Upon selection of the “Done” button on keyboard1634 or user interface element 1636, the client device app will send thetechnician’s email address to the server, which will then allow thetechnician to log in and will then allow the vehicle information fromthe ODB2 port of the vehicle to be shared with a second client devicethat is operated by a technician. Sharing the vehicle information withthe technician’s client device allow the technician to diagnose thevehicle, even when the vehicle and the technician are remotely located.

Referring to FIGS. 17A, 17B, 17C, upon selection of user interfaceelement 1610 from menu 1602, user interface 502 displays view 1702. View1702 may be referred to as “Diagnostics” view 1702 and displays list1704 of diagnostic codes with a text description of the code. List 1704is a list that can be scrolled up and down to show more than one page ofinformation. FIG. 17B shows the top of list 1704 and FIG. 17C shows thebottom of list 1704.

Referring to FIGS. 18A and 18B, upon selection of user interface element1612 from menu 1602, user interface 502 displays view 1802. View 1802,which may be referred to as “Datalog” view 1802, displays list 1804 ofdata logs, below which is user interface element 1806. List 1804 is ascrollable list that shows the data logs that can be sent to the systemserver. The data logs store information received by the client devicefrom the local device that the local device received from the automotivecontroller. Selecting user interface element 1806 sends a data log thathas been selected from list 1804 to the system server.

Referring to FIGS. 19A, 19B, 19C, and 19D, upon selection of userinterface element 1614, user interface 502 displays view 1902. View1902, which may also be referred to as “Settings” view 1902, displaysone or more user interface elements that allow the user of the app toview and control various settings related to the app.

User interface element 1904 displays contact information including aname and an email address. When user interface element 1904 is selected,user interface 502 displays another view (not shown) that allows theuser to view and manipulate the contact information, which also includesa phone number and a birthday. The contact information is used by thetechnician to contact the owner of the vehicle that the local device isconnected to.

When selected, user interface element 1906 displays one or more videosthat show how to use the client device app.

User interface element 1908 is for the development of the client deviceapplication itself. When user interface element 1908 selected, theclient device app will send the log of information recorded by theclient device app via an email to the contact identified in userinterface element 1904.

User interface element 1910 displays the version of the client deviceapp that is currently running.

User interface element 1912 displays the version of the firmware runningon the local device that is currently running.

User interface element 1914 displays a receive signal strength indicator(RSSI) that indicates the strength of the wireless signal that is sentby the local device and received by the client device.

User interface element 1916 is an edit box that contains the internetprotocol (IP) address that the client device will use to connect to theserver running on the local device.

User interface element 1918 is a binary selector switch that, whenenabled, allows the app to connect to the server running on the localdevice.

User interface element 1920 is a multiple position single selectorswitch that is used to select which protocol version that the clientdevice app will use to communicate with the server running on the localdevice.

Referring to FIG. 20A, server database 20100 is an embodiment ofdatabase 106 that is accessed by system server 102 of FIG. 1 . Serverdatabase 20100 comprises one or more records, which may themselves bedatabases. The records can be stored on any device of the system. In oneembodiment, server database 20100 includes records for vehicles 20102,technicians 20104, and ECU profiles 20106.

Vehicles 20102 comprise vehicle records 20200 of FIG. 20B that are eachassociated with a vehicle. Technicians 20104 comprise technician records20300 that are each associated with a technician. ECU profiles 20106comprise ECU profile records 20400 that are each associated with an ECUprofile.

Referring to FIG. 20B, vehicle record 20200 comprises data andinformation related to a vehicle. Vehicle identification number (VIN)20202 is a unique number that is assigned to the vehicle by themanufacturer of the vehicle in accordance with international standardISO 3833. Year 20204 is the model year of the vehicle, which in oneembodiment is stored as an unsigned integer. Make 20206 identifies themanufacturer of the vehicle, which in one embodiment is stored as astring of characters in accordance with either the American StandardCode for Information Interchange (ASCII) or Unicode. Model 20208identifies the model of the vehicle, which in one embodiment is storedas a string of characters. Technicians 20210 are links to technicianrecords 20300 for each technician that has been associated with thevehicle. ECU profiles 20212 are links to ECU profile records 20400 foreach ECU profile that has been associated with the vehicle.

Referring to FIG. 20C, technician record 20300 comprises data andinformation associated with a technician. Name 20302 is the name of thetechnician, which in one embodiment is stored as a string of characters.Email 20304 is an email address of the technician that may also serve asa login identifier for the technician and which, in one embodiment, isstored as a string of characters. Vehicles 20308 are links to vehiclerecords 20200 that are associated with the technician. Client devicedata 20310 includes data and information about the device that thetechnician uses to access the system, including: a unique deviceidentifier, operating system (OS) version, client application version,and so on.

Referring to FIG. 20D, ECU profile record 20400 comprises data andinformation associated with an ECU profile. ECU profile record 20400includes firmware 20402 and includes parameters 20408.

Firmware 20402 is the firmware that runs on an automotive controller,such as vehicle device 114 of FIG. 1 . Firmware 20402 includes code20404 and settings 20406. Code 20404 are the computer code instructionsthat allow the automotive controller to operate. Settings 20406 are thesettings used to tune the engine for efficiency or performance,including settings for ignition timing advance, spark timing, fuelinjection, electronic throttle control, poppet valve timing, boostcontrol, an anti-lock braking system, an automatic transmission, a speedgovernor, an electronic stability control system, and so forth.

Parameters 20408 are the parameters for the gauges displayed on a clientdevice, such as client device 110 of FIG. 1 . Parameter identifier (PID)20410 is a numeric identifier that uniquely identifies the type of datafrom the automotive controller associated with the parameter. Name 20412identifies the name of the parameter, which can include: engine coolanttemperature, speed, revolutions per minute, battery voltage,transmission temperature, boost, calculated load, injector pressure,injector pulse width, throttle position sensor, and so on. Desired max20414 is a numerical value that indicates a maximum desired value forthe parameter. Desired min 20416 is a numerical value that indicates aminimum desired value for the parameter.

Warning max 20418 is a numerical value that indicates the beginning ofan upper warning range. Warning min 20420 is a numerical value thatindicates the end of a lower warning range. Continued operation of thevehicle with the values associated with the parameter above warning max20418 or below warning min 20420 could lead to a breakdown of theengine.

Defuel max 20422 is a numerical value that indicates the threshold abovewhich the vehicle will be defueled to prevent a breakdown. Defuel min20424 is a numerical value that indicates the threshold below which thevehicle will be defueled to prevent a breakdown.

Gauge style 20426 identifies the style of the gauge that will be used todisplay the parameter values on the client device.

Available units 20428 is a list of units that can be used to display thevalues related to parameter 20408. Selected units 20430 identifies whichunits of available units 20428 will be used to display the values ofparameter 20408.

Referring to FIG. 21 , system 2102 is a system within local device 112of FIG. 1 . A preferred embodiment of local device 112 includes theFreescale IMX28 Microcontroller, a UART for translation between paralleland serial data forms, Wi-Fi connectivity employing the IEEE 802.11standard or other wireless protocol for communication between clientdevice 110 and the local device 112 and provisions for a localinterconnect network LIN for communication between vehicle componentsand a CAN BUS for communication between microcontrollers and otherdevices. System 2102 includes application processor 2104 that controlslocal device 112. System 2102 includes: external memory interface (EMI)2106, general-purpose media interface (GPMI) 2108, synchronous serialport (SSP) 2110 and controller area network (CAN) interfaces 2112 and2114.

EMI 2106 is connected to memory 2116 and GPMI 2108 is connected tomemory 2118. In one embodiment, memory 2118 is lower speed persistentmemory that stores the programs and data run by application processor2104 using memory 2116.

SSP 2110 is connected to Wi-Fi module 2120 to allow for wirelesscommunication. In one embodiment, program instructions stored one ormore of memory 2116 and memory 2118 are executed by applicationprocessor 2104 so that local device 112 may function as an access pointto which a client device can connect.

CAN0 interface 2112 is connected to a first CAN transceiver 2124 of avehicle via the CAN0_HI/LOW link 2165 to connector 2122. CAN1 interface2114 is connected to a second CAN transceiver 2126 through analogmultiplexer 2128 and connector 2122. Analog multiplexer 2128 isconnected to connecter 2122 through a CAN1_HI_B/LOW_B line 2164 and aCAN1_HI_C/LOW_C line 2166. Input/Output multiplexor control 2113 is alsoconnected to analog multiplexer 2128. In one embodiment, connector 2122is an RJ45 connector and an adapter (not shown) is connected betweenconnector 2122 and the on-board diagnostics (OBD) port on the vehicle.

Analog multiplexer 2128 is controlled by an output signal frominput/output multiplexor control 2113 of application processor 2104 toselect between line 2164 and line 2166 for the CAN1 interface. Thisallows the system to be connected to different vehicles that usedifferent pins on an OBD port for the second CAN interface (i.e., CAN1).

SMT (suface mount) test pads 2130 are the physical access points to I2C0bus 2140. I2C0 bus 2140 allows for connecting application processor 2104to external peripherals that operate in accordance with the I2Cinterface standard.

Debug connector 2132 is the physical access point for several debuggingports on application processor 2104 including UART0 2142, JTAG 2144,power switch pin 2146, and reset pin 2148. UART0 2142 (universalasynchronous receive transmit) is a serial port that allows forconnecting application processor 2104 to external peripherals that use aserial bus interface. JTAG 2144 is a port that allows for access usingwith peripherals the Joint test Action Group standard for debuggingports. Power switch pin 2146 is an input to application processor 2104that is used to indicate when application processor 2104 should poweroff and can be activated with push button 2136. Reset pin 2148 is aninput to application processor 2104 that is used to reset applicationprocessor 2104 and which can be activated with push button 2134.

Push button 2134 is a physical button that can be used to resetapplication processor 2104. Activation of push button 2134 triggersreset pin 2148 of application processor 2104 to cause applicationprocessor 2104 to reset.

Push button 2136 is a physical button that can be used to power downprocessor 2104 upon the activation of push button 2136.

SD card connector 2138 is the physical interface used to connect an SDcard to application processor 2104 through SSP0 2150. SSP0 2150 is asynchronous serial port interface used to connect application processor2104 to external memory.

LCD pins 2152 are connected to switch 2158. Switch 2158 sets LCD pins2152 to identify the memory from which processor 2104 will attempt toboot after powering on.

GPIO pins 2154 are connected to LEDs 2160. In a preferred embodiment,LEDs 2160 include a red LED that activates to indicate an error, a blueLED that provides the status of a wireless connection, and a green ledto indicate that the system is powered on.

USB port 2156 is a universal serial bus (USB) port on processor 2104that is used to connect processor 2104 to external devices that utilizethe universal serial bus protocols and standards. USB port 2156 isattached to USB connector 2162, which provides the physical connectionfor external peripherals.

Referring to FIG. 22 , system 22000 includes servers (22008 and 22020)and devices (22032, 22046, 22060, 22074, and 22090) that each contain atleast one processor (22010, 22022, 22034, 22048, 22062, 22076, and22092), at least one memory (22012, 22024, 22036, 22050, 22064, 22078,and 22094), and at least one network connection (22018, 22030, 22042,22044, 22056, 22058, 22070, 22072, 22084, 22086, 22088, and 22100). Thenetwork connections are used to communicate messages, data, information,code, instructions, alerts, and notifications (22016, 22028, 22040,22054, 22068, 22082, and 22098) through the system using one or morenetworks (22002, 22004, and 22006). The servers and devices executeprograms, program code, instructions, and applications (22014, 22026,22038, 22052, 22066, 22080, and 22096) stored in memory that cause theservers and devices to activate and execute programs in response to themessages passed through the system. In a preferred embodiment, theservers and devices are activated in response to messages that weretransmitted over a wireless network and that include instructions toactivate the user client device and execute one or more programs,instructions, and code. In a preferred embodiment, each messagetransmitted in the system includes a cryptographic hash value that isgenerated from the data within the message, a random number, and acryptographic hash value provided by system 22000, where a number ofcontiguous bits with the cryptographic hash value that have the samevalue (0 or 1) is greater than a predetermined threshold.

Internet 22002, mobile network 22004, and vehicle network 22006 providenetwork access to the servers and devices of system 22000 so that dataand information may be exchanged between the devices and servers ofsystem 22000. Each of networks 22002, 22004, and 22006 include one ormore routers, switches, wireless connections, and wired connections thatare utilized by the servers and devices of system 22000 to communicate.

Administration server 22008 includes, or has access to, databases thatstore all of the data and information used by system 22000, whichincludes account information for technicians that use technician clientdevice 22046, account information for customers that use customer clientdevice 22060, local device information, and vehicle information relatedto vehicle device 22090. Administration server 22008 manages thisinformation and provides access to this information through a websitethat is accessible by technician client device 22046, administratordevice 22032, and customer client device 22060. Administration server22008 also stores ECU profiles that are provided to technician clientdevice 22046 on demand. Administration server 22008 is a cloud serverthat enables remote access to the data and information from vehicledevice 22090 to technician client device 22046.

Third-party server 22020 provides access to one or more ECU profilesthat can be accessed and retrieved upon request by administration server22008. In some embodiments, the third-party server 22020 includes amotor authority server configured to receive ELD data such as RODS.

Administrator device 22032 is used to monitor, control, and manageadministration server 22008. Administrator device 22032 is used toreview, manage, and update the accounts controlled by administrationserver 22008.

Technician client device 22046 is used to diagnose the vehicle in whichvehicle device 22090 is installed. Technician client device 22046 sendsand receives messages, data, and information with administration server22008 through one or more networks, such as internet 22002 and mobilenetwork 22004. Technician client device 22046 displays live data, loggeddata, and ECU profiles that are related to vehicle device 22090 and havebeen received from vehicle device 22090 through system 22000. Withtechnician client device 22046, a technician can review live data andlogged data and then edit an ECU profile that is customized based on thelive data and the log data and is sent to vehicle device 22090.

In some embodiments, system 22000 includes, instead of technician clientdevice 22046, a motor authority or safety office client device that iscommunicationly coupled with the motor authority server.

Customer client device 22060 is used to create a connection betweenlocal device 22074 and the rest of system 22000, so that administrationserver 22008 can receive the live data, logged data, and ECU profiledata from vehicle device 22090. Customer client device 22060 also allowsfor the display of the live and logged data generated by vehicle device22090 and received through local device 22074 through vehicle network22006. Customer client device 22060 stores ECU profiles that can be usedby vehicle device 22090 and a user of customer client device 22060 canselect one of the ECU profiles to be sent to local device 22074 to beloaded onto vehicle device 22090.

Local device 22074 operates to receive data from vehicle device 22090 sothat the vehicle data may be published to administration server 22008 aswell as to customer client device 22060. The connection between localdevice 22074 and administration server 22008 can be through vehiclenetwork 22006 with network connection 22086 which utilizes customerclient device 22060 as a pass-through to reach administration server22008. Additionally, network connection 22084 can be utilized so thatlocal device 22074 transmits the vehicle data to mobile network 22004and is eventually received by administration server 22008 throughinternet 22002. Utilizing network connection 22084 to mobile network22004, instead of network connection 22086 to vehicle network 22006creates a more direct connection between local device 22074 andadministration server 22008. In a preferred embodiment, networkconnection 22088 of local device 22074 is connected to networkconnection 22100 of vehicle device 22090, which is an OBD port.

Vehicle device 22090 manages the sensors, systems, and devices that areutilized to operate a vehicle. After a connection is established withlocal device 22074, vehicle device 22090 publishes data and informationabout the vehicle and receives commands from local device 22074. Thecommands received by vehicle device 22090 from local device 22074 areexecuted by vehicle device 22090 to operate the systems, sensors, anddevices of the vehicle. Stored in memory 22094 of vehicle device 22090,is at least one ECU profile that contains one or more settings,parameters, codes, and instructions that are utilized by vehicle device22090 to control operation of the vehicle into which vehicle device22090 is installed. In a preferred embodiment, vehicle device 22090 isan engine control unit.

Referring to FIGS. 23A through 23G, method 23000 details the severalsteps utilized by system 22000 to perform the operations of acquiringtokens for a technician to use system 22000 with technician clientdevice 22046, displaying logged data, displaying live data, and updatingECU profiles using cloud services provided by administration server22008. For example, a customer can call a technician and ask for helpwith diagnosing their vehicle. The technician uses technician clientdevice 22046 to connect to vehicle device 22090 through system 22000.The technician reviews logged vehicle data and live vehicle data that isprovided through system 22000. System 22000 recommends, based on thevehicle data, updates to the ECU profile that is being used by vehicledevice 22090. The technician customizes and updates the suggested ECUprofile and instructs system 22000 to download the ECU profile tovehicle device 22090.

Referring to FIG. 23A, at step 23020, technician client device 22046selects a token acquisition request. The selection is made by atechnician using technician client device 22046. In a preferredembodiment, a technician must acquire tokens that are associated with atechnician account that is maintained by administration server 22008.The tokens are used to enable the functionality and cloud servicesprovided by administration server 22008 within system 22000.

At step 23022, technician client device 22046 generates a tokenacquisition request alert. The alert identifies the number of tokensthat the technician has elected to acquire and includes data, code, andinstructions that, after being received by administration server 22008,will activate administration server 22008 and cause administrationserver 22008 to process the acquisition request.

At step 23024, the token acquisition request alert is sent fromtechnician client device 22046 to administration server 22008.

At optional step 23026, administration server 22008 processes the tokenacquisition request alert. The processing includes determining whetheror not additional human interaction is needed to approve the tokenacquisition request, with the processing based on the account history ofthe technician, the current technician account status, technician clientdevice 22046, and any comments received from customers that relates tothe technician. In a preferred embodiment, human interaction will beneeded when the account history indicates, that a previous tokenacquisition request was not approved, that the current technicianaccount status indicates that there is incorrect contact information forthe technician, that technician client device 22046 is not using thelatest version of the cloud services application, and that the ratio ofpositive customer comments to negative customer comments is below apredefined threshold (e.g., 9 to 1). In a preferred embodiment,administration server 22008 also identifies a likelihood that therequest will be granted and gathers additional information about thetechnician, the technician account, and technician client device 22046that are consolidated and added to the token acquisition request alertto be reviewed by a user of administrator device 22032 to make a finaldetermination as to whether the token acquisition request will beapproved.

At optional step 23028, the token acquisition request alert is sent fromadministration server 22008 to administrator device 22032. In apreferred embodiment, the request alert includes the injectedinformation of the likelihood of approval and the consolidatedinformation about the technician.

At optional step 23030, the token acquisition request is displayed byadministrator device 22032. The request alert received by administratordevice 22032 from administration server 22008 includes one or moreinstructions, data, and code that, when processed by administratordevice 22032, triggered the display of the information within the tokenacquisition request alert. The information within the token acquisitionrequest alert includes the token acquisition request itself plus theinjected information.

At optional step 23032, a token acquisition approval notification isgenerated by administrator device 22032. In a preferred embodiment, theapproval notification is generated in response to interaction with auser that reviews all of the information related to the acquisitionrequest. The notification identifies whether the acquisition requestwill be approved or denied.

At optional step 23034, the token acquisition approval notification istransmitted from administrator device 22032 and subsequently received byadministration server 22008.

At step 23036, administration server 22008 generates a token acquisitionapproval. The final determination for the token acquisition request isbased on one or more of several factors, including, the technicianaccount history, the technician account status, the status of technicianclient device 22046, the status of the application running on technicianclient device 22046, and user input that was collected and supplied byadministrator device 22032. The token acquisition approval includes anindication of whether the token acquisition request was approved ordenied, and the number of tokens that were approved, if any. In apreferred embodiment, the approval also includes a cryptographic hash ofall of the information used to generate the approval. In a preferredembodiment, the cryptographic hash is performed using one of the securehash algorithms SHA-0, SHA-1, SHA-2, or SHA-3.

At step 23038, tokens are generated by administration server 22008. Thegeneration of the tokens is based on the token acquisition approval tosatisfy as much of the request that was approved. In a preferredembodiment, each token generated is a record in a database that ismanaged by administration server 22008. Each token record is serializedand includes an indicator value which indicates whether or not the tokenhas been used. In a preferred embodiment, the token is hashed andcompressed to allow it to be efficiently communicated to the variousnodes and which lessens the likelihood of data corruption. Each node iscapable of opening and operating on the token in order to change itsstatus from “not used” to “used” and to update parameters associatedwith the delivery of goods or services. Each token includes and isassociated with the technician account associated with the acquisitionrequest. Tokens that have not been used to enable functionality ofsystem 22000 are indicated as available. Tokens are no longer validafter being used to enable a function requested by the technician usingtechnician client device 22046.

Each record of a used token includes a graphic hash value created usingtechnician information, technician account information, customerinformation, vehicle information, function information, and a date timestamp. In a preferred embodiment, the technician information identifiesthe technician that used the token one or more of a unique identifierfor the technician, an email address of the technician, and the firstand last name of the technician. The technician account informationincludes one or more of a unique identifier for the technician account,a unique database identifier for technician client device 22046, and aunique identifier and hash value for the application running ontechnician client device 22046. The customer information identifies thecustomer that is related to the vehicle upon which the function is usedand includes one or more of a unique database identifier of thecustomer, an email address at the customer, a first and last name of thecustomer, and a telephone number of the customer. The vehicleinformation identifies the vehicle upon which the function was used andincludes one or more of a vehicle identification number, unique databaseidentifier of the vehicle, and a license plate number of the vehicle.The function information identifies the function for which the token wasexchanged, such as the functions of receiving log vehicle data,receiving live vehicle data, receiving ECU profiles, and sending ECUprofiles. The date time stamp indicates one or more of the date and timethat the token was exchanged for the function and when the function wasactivated and used by the technician client device 22046.

At step 23040, administration server 22008 generates a token acquisitionapproval alert. The token acquisition approval alert includes the tokenacquisition approval or includes instructions, code, or data that can beused to locate the token acquisition approval by a client device.

At optional step 23042, the token acquisition approval alert istransmitted from administration server 22008 and subsequently receivedby administrator device 22032. In a preferred embodiment, the tokenacquisition approval alert is sent to administrator device 22032 whenthe technician account status requires the approval alert to be sent toadministrator device 22032, or when a user of administrator device 22032that approved the request indicated that the approval alert should besent.

At optional step 23044, the token acquisition approval alert isdisplayed by administrator device 22032.

At step 23046, the token acquisition approval alert is transmitted fromadministration server 22008 and subsequently received by technicianclient device 22046.

At step 23048, the token acquisition approval is displayed by technicianclient device 22046. Display of the token acquisition approval includesdisplay of the number of tokens that were approved, if any, which waseither included in the token acquisition approval alert or was retrievedby technician client device 22046 from administration server 22008 usinginformation included in the token acquisition approval alert.

Referring to FIG. 23B, at step 23050, a customer list, a vehicle list,and a function list are generated by administration server 22008. Theentries for each list are customized based on technician client device22046 and the technician account that is related to technician clientdevice 22046.

At step 23052, administration server 22008 sends the customer list, thevehicle list, and the function list, which are received by technicianclient device 22046. Each of the lists and their entries may be sent ondemand or in batch and in response to user interaction with technicianclient device 22046.

At step 23054, technician client device 22046 selects the customer fromthe customer list. In order for a customer to appear in the customerlist, the customer must have identified the technician as an approvedtechnician using the customer client application with customer clientdevice 22060.

At step 23056, the vehicle from the vehicle list is selected bytechnician client device 22046. In a preferred embodiment, the vehiclesin the vehicle list are highlighted and/or sorted to identify thevehicle that contains vehicle device 22090 and is connected to localdevice 22074.

At step 23058, the function from the function list is selected bytechnician client device 22046. Functions include: displaying live datafrom the vehicle, displaying logged data from the vehicle, displayingthe current ECU profile that is being used by vehicle device 22090, anddownloading a new ECU profile to vehicle device 22090. Each functionincludes a value of the number of tokens needed to access and utilizethat function.

At step 23060, a function request alert is generated by technicianclient device 22046. The function request alert include data,information, and code that identifies one or more of technician clientdevice 22046, the technician using technician client device 22046, theselected customer, the selected vehicle, and the selected function. In apreferred embodiment, the request alert also includes a cryptographichash value created from (i) the selection data and (ii) a cryptographichash value that was provided to technician client device 22046 byadministration server 22008.

At step 23062, the function request alert is transmitted from technicianclient device 22046 and subsequently received by administration server22008.

At step 23064, administration server 22008 compares the available tokensto the required tokens. Each function request requires a predefinednumber of tokens to enable that function. The predefined number oftokens for each function is determined based on one or more formulas. Afirst formula sets a constant number of tokens for the function. Asecond formula increases the number of tokens by the type of vehiclewith each type, make, model, and brand of vehicle being associated withdifferent numbers of tokens. A third formula increases the number oftokens by the type of function requested with each function beingassociated with a specific number of tokens. After determining thenumber of tokens that are required for the selected function,administration server 22008 determines if the technician accountassociated with technician client device 22046, which provided thefunction request, includes enough tokens to activate the requestedfunction.

At step 23066, administration server 22008 generates the functionrequest approval. When the comparison of the available tokens in thetechnician account to the tokens required for the function requestindicate that there are enough available tokens in the technicianaccount, the function request is approved. Otherwise the functionrequest is denied. An indication of whether the request has beenapproved or denied is included with the functional request approval.

At step 23068, administration server 22008 sends the function requestapproval alert, which is received by technician client device 22046. Thefunction request approval alert includes an indication of whether thefunction request was approved and, in a preferred embodiment, alsoinclude the function request approval generated by administration server22008.

At step 23070, technician client device 22046 displays the functionrequest approval. Display of the function request approval is aftertechnician client device 22046 processes the function request approvalalert that was received from administration server 22008 and extractsthe function request approval from either the function request approvalalert, which included the function request approval, or retrieves thefunction request approval from administration server 22008 based oninformation, data, and codes contained within the function requestapproval alert.

Referring to FIG. 23C, at step 23072, vehicle data is generated byvehicle device 22090. The vehicle data includes data, information, andcode from one or more sensors, systems, and devices that are connectedto vehicle device 22090. The sensors, systems, and devices are connectedto vehicle device 22090 using a CAN bus in a preferred embodiment.

At step 23074, vehicle device 22090 sends vehicle data, which isreceived by local device 22074.

At step 23076, local device 22074 generates logged vehicle data. Thelogged vehicle data is a set of the data received by local device 22074from vehicle device 22090 that includes the vehicle data that is outputfrom vehicle device 22090 during the operation of the vehicle during aparticular time that includes one or more of revolutions per minute ofthe engine, the speed of the vehicle in miles or kilometers per hour,engine temperature in degrees Fahrenheit or Celsius, injector pressurein thousand pounds per square inch, boost pressure in pounds per squareinch, injector pulse width in milliseconds, calculated load percentage,and transmission temperature in in degrees Fahrenheit or Celsius. Togenerate the logged vehicle data, local device 22074 filters the vehicledata that was received from vehicle device 22090. The filters that areapplied to the vehicle data identify the types of vehicle data that areto be kept along with the time frame and duration for keeping thevehicle data. The timeframe identifies the length of a current window oftime for vehicle data, such as the last 10 minutes of vehicle data. Theduration identifies how long the logged data should be stored by localdevice 22074 before being discarded and includes, in a preferredembodiment, options for numbers of minutes, hours, days, weeks, andmonths.

At step 23078, a logged vehicle data request is generated by technicianclient device 22046. In a preferred embodiment, the logged vehicle datarequest is generated only after technician client device 22046 has useda valid token for that requested function from administration server22008.

At step 23080, technician client device 22046 sends the logged vehicledata request, which is received by administration server 22008. At step23081, administration server 22008 identifies the customer client device22060 and local device 22074 that are associated with the request.

At step 23082, administration server 22008 sends the logged vehicle datarequest, which is received by customer client device 22060.

At step 23084, customer client device 22060 sends the logged vehicledata request, which is received by local device 22074.

At optional step 23086, the logged vehicle data request is sent directlyfrom administration server 22008 to local device 22074.

At step 23088, the logged vehicle data is filtered by local device22074. The logged vehicle data is filtered based upon the contents ofthe logged vehicle data request that was initiated with technicianclient device 22046.

At step 23090, a logged vehicle data response is generated by localdevice 22074. The logged vehicle data response includes the vehicle datathat was filtered by local device 22074.

At step 23092, local device 22074 sends the logged vehicle dataresponse, which is received by customer client device 22060.

At optional step 23093, customer client device 22060 displays the loggedvehicle data from the logged vehicle data response.

At step 23094, customer client device 22060 sends the logged vehicledata response to administration server 22008.

At step 23095, the administration server records the logged vehicle dataresponse, and associates it with the customer client device record.

At optional step 23096, local device 22074 sends the logged vehicle dataresponse to administration server 22008.

At step 23098, administration server 22008 sends the logged vehicle dataresponse, which is received by technician client device 22046. In apreferred embodiment, administration server 22008 receives the loggedvehicle data from both customer client device 22060 and local device22074 and compares the responses to ensure that the responses were notcorrupted.

At step 23100, the logged vehicle data is displayed by technician clientdevice 22046. After receiving the logged vehicle data in the responseprovided by local device 22074 through system 22000, technician clientdevice 22046 filters the time and duration of the logged data. The timescale of the logged data can be zoomed in and out using technicianclient device 22046 to allow the technician to see the log data usingdifferent time scales and is further described in FIG. 26 .

Referring to FIG. 23D, at step 23102, the start live vehicle datarequest is generated by technician client device 22046. The start livevehicle data request identifies the customer and vehicle for which livedata is being requested. In a preferred embodiment, the request alsoincludes a cryptographic hash value generated from the data in therequest and from a cryptographic hash value received from administrationserver 22008. In a preferred embodiment, a valid token is required forthis function.

At step 23104, the start live vehicle data request is transmitted fromtechnician client device 22046 and subsequently received byadministration server 22008.

At step 23106, administration server 22008 verifies the start livevehicle data request. The verification process used by administrationserver 22008 for the start live vehicle data request from technicianclient device 22046 checks the technician account and the customeraccount to make sure that the technician is authorized by the customerto access the vehicle associated with customer account and that the livedata function has been enabled and approved for the technician accountand technician client device 22046.

At step 23108, start live vehicle data instructions are generated byadministration server 22008. After verification of the start livevehicle data request, administration server 22008 generates instructionsfor customer client device 22060, local device 22074, and/or vehicledevice 22090 that, when respectively executed by these devices, triggerthe transmission of live vehicle data from the vehicle through system20000 to technician client device 22046. In a preferred embodiment, theinstructions generated by administration server 22008 are included in analert that is transmitted to and subsequently received by local device22074.

At step 23110, administration server 22008 sends a start live vehicledata instructions alert to customer client device 22060.

At step 23112, customer client device 22060 sends the start live vehicledata instructions alert, which is received by local device 22074.

At optional step 23114, administration server 22008 sends a start livevehicle data instructions alert to local device 22074.

At step 23116, the start live vehicle data instructions are executed bylocal device 22074. The instructions include an identification of thevehicle data. In a preferred embodiment, the start live vehicle datainstructions cause local device 22074 to begin listening to the datafrom vehicle device 22090.

At step 23118, vehicle device 22090 generates live vehicle data. Thelive vehicle data includes one or more of sensor data, device settings,and system outputs that are generated by the sensors, systems, anddevices of the vehicle. In a preferred embodiment, vehicle device 22090begins generating vehicle data as soon as the vehicle is turned on, andcontinuously broadcasts it over the OBD Port of vehicle while thevehicle is running.

At step 23120, the live vehicle data is published by vehicle device22090. In a preferred embodiment, publication of the data is performedby encapsulating the vehicle data for transmission over an OBD port towhich vehicle device 22090 is connected. Each type of vehicle data isencapsulated to a predefined number of bytes using a predeterminedformula for that type of vehicle data. As an example, the absolutepressure of the intake manifold has a minimum possible value of 0, amaximum possible value of 255, is measured in kilopascals, and there isno formula to translate from the value of the intake manifold pressureto the single bite that is provided over the OBD port. In contrast,engine coolant temperature uses a single byte, has a minimum value of-40, a maximum value of 215, uses units of degrees Celsius, and usesformula of A - 40, where A is the value of the byte transferred over theOBD port. As another example, engine RPM uses two bytes, has a minimumvalue of 0, has a maximum value of 16383.75, and uses the formula 256A + B / 4, where A is the first bite and B is the second bite providedover the OBD port.

At optional step 23122, the live vehicle data is sent from vehicledevice 22090 to local device 22074.

At step 23124, local device 22074 filters the live vehicle data. Thefilters were specified in the start live vehicle data instructionsalert.

At step 23126, local device 22074 generates the live vehicle data alert.The live vehicle data alert includes the vehicle data sent from vehicledevice 22090 and filtered by local device 22074. Generation of the livevehicle data alert reformats the data that was received from vehicledevice 22090 into a format that can be transmitted to one of customerclient device 22060 and administration server 22008 by putting the datainto one or more TCP/IP packets that are used by communication networks22002, 22004, and 22006.

At step 23128, the live vehicle data alert is sent from local device22074 to customer client device 22060. In a preferred embodiment,customer client device 22060 acts as a pass through so that the livevehicle data alert is only stored temporarily in the memory of customerclient device 22060. In an additional embodiment, customer client device22060 also extracts and stores the vehicle data from the live vehicledata alert to non-volatile memory of customer client device 22060 anddisplays it on a screen of customer client device 22060.

At optional step 23129, customer client device 22060 displays the livevehicle data from the live vehicle data alert.

At step 23130, the live vehicle data alert is sent from customer clientdevice 22060 to administration server 22008.

At optional step 23132, the live vehicle data alert is transmitted fromlocal device 22074 directly to administration server 22008.

At step 23133 the administration server stores the live vehicle dataalert and associates it with the customer client device.

At step 23134, administration server 22008 sends the live vehicle dataalert to technician client device 22046.

At step 23136, technician client device 22046 displays the live vehicledata. In a preferred embodiment, the live vehicle data is displayed inone or more graphs, tiles, and gauges in an application window of anapplication running on technician client device 22046.

Referring to FIG. 23E, at step 23138, technician client device 22046generates a stop live vehicle data request, as will be described furtherlater. In a preferred embodiment, the stop live vehicle data request isgenerated in response to interaction with a technician using technicianclient device 22046 after the technician has viewed enough of the livevehicle data from the vehicle and triggers the generation of the stoplive vehicle data request using one or more gesture inputs that arecaptured by technician client device 22046. The stop live vehicle datarequest includes one or more of code, data, information, andinstructions that cause one or more of administration server 22008,customer client device 22060, local device 22074, and vehicle device22090 to stop publishing live vehicle data.

At step 23140, technician client device 22046 sends the stop livevehicle data request, which is received by administration server 22008.In a preferred embodiment, administration server 22008 is activated inresponse to receipt of the stop live vehicle data request and executescode, data, and instructions within the stop live vehicle date ofrequest to stop the transmission of live vehicle data, as describedbelow.

At step 23142, administration server 22008 verifies the stop livevehicle data request. In a preferred embodiment, verification of thestop live vehicle data request includes verifying that live data iscurrently being published and that technician client device 22046 is thedevice that initiated the publication of the live vehicle data.

At step 23144, administration server 22008 generates stop live vehicledata instructions. When executed by at least one of customer clientdevice 22060 and local device 22074, the instructions stop thepublication of the live vehicle data that is being provided by thevehicle device 22090.

At step 23146, administration server 22008 sends the stop live vehicledata instructions alert, which is received by customer client device22060.

At step 23148, customer client device 22060 sends the stop live vehicledata instructions alert, which is received by local device 22074.

At optional step 23150, administration server 22008 sends the stop livevehicle data instructions alert, which is received by local device22074.

At step 23152, the stop live vehicle data instructions are executed bylocal device 22074. Execution of the instructions causes local device22074 to stop publishing the live vehicle data that is continuouslybroadcast by vehicle device 22090.

Referring to FIG. 23F, at step 23154, technician client device 22046generates a technician active ECU profile request. For example, afterviewing logged vehicle data and live vehicle data, the technician usingtechnician client device 22046 decides to review the ECU profile that isbeing used by vehicle device 22090. The technician may view the currentECU profile at any time before or after viewing the logged vehicle dataand live vehicle data by interacting with the user interface of theapplication running on technician client device 22046. In a preferredembodiment, technician client device 22046 detects a gesture that isassociated with selecting a button that is displayed on the userinterface of the application running on technician client device 22046.

At step 23156, technician client device 22046 sends the technicianactive ECU profile request, which is received by administration server22008.

At step 23158, a server active ECU profile request is generated byadministration server 22008. As a part of the request generation,administration server 22008 also verifies that technician client device22046 and the technician account associated with technician clientdevice 22046 is authorized to make the active ECU profile request forthe vehicle into which vehicle device 22090 is installed and thecustomer associated with the vehicle. If unauthorized use is detected,administration server 22008 sends one or more control signals to theclient device, which sends the signals to local device 22074 forimplementation. In a preferred embodiment, the control signals cancomprise an interrupt request, a POR_B reset signal, an OCOTP_CTRLsignal including a volatile software-accessible signal that enables ordisables software control of a hardware element, an ARM TrustZonesignal, a cryptographic acceleration and assurance module (CAAM) signal,a central security unit (CSU) signal, an advanced high assurance boot(A-HAB) signal, a programmable polyfuse signal, a unique chip identifiersignal, a mask revision number signal, a cryptographic key signal, aJTAG secure mode signal, a TZ WDOG security violation signal, orcombinations thereof. In a preferred embodiment, the control signals arecompatible with the i.MX 6SoloX chipset available from NXPSemiconductors, Netherlands B.V. If the use is authorized, in apreferred embodiment, administration server 22008 generates and includesin the request data, code, and instructions that are executed by localdevice 22074 to extract the ECU profile from vehicle device 22090.

At step 23160, administration server 22008 sends the server active ECUprofile request to customer client device 22060.

At step 23162, the server active ECU profile request is transmitted fromcustomer client device 22060 and subsequently received by local device22074.

At optional step 23164, the server active ECU profile request is sentfrom administration server 22008 to local device 22074.

At step 23166, local device 22074 generates a local device active ECUprofile request. The profile request is a set of instructions thatcauses vehicle device 22090 to transmit the active ECU profile back tolocal device 22074. In a preferred embodiment, instructions are machinelanguage code executable by vehicle device 22090 which identifiesparameter identifier (PID) values in accordance with the controller areanetworks (CAN) bus and OBD protocols.

At step 23168, local device 22074 sends the local device active ECUprofile request to vehicle device 22090.

At step 23170, vehicle device 22090 retrieves the active ECU profile.Vehicle device 22090 retrieves all of the settings, parameters, codes,and instructions that are currently being utilized to operate thevehicle.

At step 23172, vehicle device 22090 generates an active ECU profilealert. In a preferred embodiment the active ECU profile alert includesthe settings, parameters, and codes that were retrieved by vehicledevice 22090.

At step 23174, vehicle device 22090 sends the active ECU profile alertto local device 22074.

At step 23176, local device 22074 forwards the active ECU profile alertto customer client device 22060. In a preferred embodiment, local device22074 stores a cached copy of the active ECU profile that was receivedfrom vehicle device 22090. For subsequent ECU profile requests wherelocal device 22074 has not issued any commands to vehicle device 22090that would change the ECU profile and within a predetermined duration oftime (e.g., ten minutes), local device 22074 sends the cached version ofthe ECU profile in response to the active ECU profile request.

At optional step 23177, customer client device 22060 displays the ECUprofile from the active ECU profile alert.

At step 23178, customer client device 22060 sends the active ECU profilealert to administration server 22008. In a preferred embodiment,customer client device 22060 also stores a cached version of the currentECU profile being used by vehicle device 22090.

At optional step 23180, local device 22074 sends the active ECU profilealert, directly to administration server 22008.

At step 23182, the active ECU profile alert is sent from administrationserver 22008 to technician client device 22046. In a preferredembodiment, administration server 22008 stores a cached copy of theactive ECU profile.

At step 23184, technician client device 22046 displays the active ECUprofile.

Referring to FIG. 23G, at step 23186, technician client device 22046generates an available ECU profile request. The generation of theavailable ECU profile request is in response to interaction with thetechnician using technician client device 22046. The technician performsone or more gestures and actions that are detected by technician clientdevice 22046 and are associated with one or more user interface elementsthat are displayed by the application that is running on technicianclient device 22046. In a preferred embodiment, the request for theavailable ECU profiles can be generated at any time during or after theprocess of diagnosing the vehicle, including before or after viewing thelogged vehicle data or the live vehicle data, or before or afterrequesting the current ECU profile from vehicle device 22090. Forexample, a technician that is diagnosing the vehicle may view the loggedvehicle data first, then view the live vehicle data, then request thecurrent ECU profile, and then request the available ECU profiles thatcan be downloaded to the vehicle.

At step 23188, technician client device 22046 sends the available ECUprofile request to administration server 22008. At step 23189,administration server 22008 locates at least one third-party server fromwhich to request at least one available ECU profile. In a preferredembodiment, multiple third-party servers can provide ECU profiles fordifferent vehicles. Examples of such third-party servers are servers atvehicle manufactures or OEM dealers.

At step 23190, the available ECU profile request is transmitted fromadministration server 22008 and subsequently received by third-partyserver 22020.

At step 23192, third-party server 22020 determines an available ECUprofile. The available ECU profile is selected based upon the type ofvehicle, make, model, manufacturer, and any other parameters included inthe request. Other parameters included in the request identify a type ofprofile such as a high-performance profile and a high-mileage profile.

At step 23194, third-party server 22020 generates an available ECUprofile alert. The available ECU profile alert includes the availableECU profile that was determined and selected by third-party server22020. The available ECU profile alert may also include data, code, andinstructions that when executed, downloads the available ECU profiledirectly from third-party server 22020.

At step 23196, an available ECU profile alert is sent from third-partyserver 22020 to administration server 22008. In a preferred embodiment,administration server 22008 also receives and caches the available ECUprofile from third-party server 22020, either by copying the availableECU profile from within the available ECU profile alert or by usingcodes and instructions from the ECU profile alert to download the ECUprofile from third-party server 22020.

At step 23198, the available ECU profile alert is transmitted fromadministration server 22008 to technician client device 22046.

At step 23200, the available ECU profile is displayed by technicianclient device 22046. Display of the ECU profile is further described inrelation to FIG. 27 .

At step 23202, an ECU profile is selected by technician client device22046. The selected ECU profile is identified from a set of ECU profilesthat are stored on administration server 22008 or technician clientdevice 22046 and that are each configured to operate the vehicle intowhich vehicle device 22090 is installed.

At step 23204, ECU profile updates are generated by technician clientdevice 22046. The updates to the selected ECU profile are generated inresponse to an analysis of the logged vehicle data, an analysis of thelive vehicle data, or interaction between technician client device 22046and the technician diagnosing the vehicle.

At step 23206, technician client device 22046 generates an ECU profileupdate alert. The ECU profile update alert includes all of the updatesto the ECU profile that were determined by technician client device22046 and the technician.

At step 23208, the ECU profile update alert is sent from technicianclient device 22046 to administration server 22008. At step 23209,administration server 22008 stores and caches the updates with amodified ECU profile that includes the ECU profile updates.Administration server 22008 then generates a subsequent ECU profileupdate alert that includes either the modified ECU profile or theupdates to the selected ECU profile.

At step 23210, the ECU profile update alert is sent from administrationserver 22008 to customer client device 22060.

At optional step 23211, customer client device 22060 displays theupdated ECU profile from the ECU profile update alert.

At step 23212, customer client device 22060 sends the ECU profile updatealert, which is received by local device 22074.

At optional step 23214, administration server 22008 sends the ECUprofile update alert to local device 22074.

At step 23216, the ECU profile is forwarded from local device 22074 tovehicle device 22090. In a preferred embodiment, the ECU profile isincluded in the ECU profile update alert.

At step 23218, vehicle device 22090 applies the ECU profile. Vehicledevice 22090 applies the ECU profile by updating one or more enginesettings and parameters based upon the ECU profile updates and operatingthe engine according to the updated settings and parameters. As anexample, the updated settings and parameters, may provide for increasedmileage or increase performance of the vehicle.

Referring to FIGS. 24A and 24B, user interface 2400 displays gauges andgraphs based on live vehicle data that is received from a local devicethat received the live vehicle data from a vehicle device. Userinterface 2400 is part of an application that runs on one or moretechnician client devices and customer client devices. The datadisplayed with user interface 2400 can be directly from a local device,or from an administration server that received the data after the datawas transmitted from a local device. User interface 2400 includesseveral user interface elements.

Referring to FIG. 24A, gauges button 2406 (further described below) hasbeen selected to show vehicle data using gauges on user interface 2400.

Button 2402 is a menu button that, once selected, brings up a main menu.The main menu allows the user to select different functions within theapplication.

Button 2404 is a user interface elements that, upon being selected,shows vehicle data using tiles, such as that described in relation toFIGS. 5 through 13 . Selection of gauges button 2406 displays vehicleinformation using gauges, as shown in FIGS. 24A through 24D. Graphsbutton 2408 is a user interface that, when selected, shows vehicle datausing graphs, as further described with FIGS. 25A through 25D.

Indicator 2410 displays a code that identifies the protocol being usedto connect to a local device. Indicator 2412 indicates whether or not aconnection is currently present with a local device.

Gauges 2414, 2416, 2418, 2420, 2422, 2424, 2426 and 2428 each showvehicle data that has been received from a local device. Gauges 2414,2416, 2418, 2420, 2422, 2424, 2426 and 2428 are each updated with livevehicle data. Gauges 2414, 2416, and 2418, are shown as circular dialsand gauges 2420, 2422, 2424, 2426 and 2428 are shown as linear gauges.

Button bar 2430 includes buttons that are used by the operating systemrunning on a client device to manipulate the current application and toswitch between other applications.

Referring to FIG. 24B, gauge 2414 has been selected and causes severalupdates to the user interface elements that are displayed on userinterface 2400. The buttons and indicators at the top of the screen havebeen removed and replaced by control 2432, which indicates that thecurrent screen being displayed is a dashboard configuration screen andthat can be canceled from using the x button.

The display of all of gauges 2414, 2416, 2418, 2420, 2422, 2424, 2426and 2428 has been scaled down to make room for selection bar 2434.Selection bar 2434 allows for the selection of the type of vehicle datathat will be displayed with the currently selected gauge by selecting abutton within selection bar 2434, such as button 2436 to display theinjector pressure of the vehicle.

Gauge 2414 is outlined and highlighted to indicate that gauge 2414 hasbeen selected. Button 2436 is oversized and highlighted to indicate thatbutton 2436 is the button that has been selected from selection bar2434.

Referring to FIG. 24C, the orientation of the client device is changedfrom a portrait orientation to a landscape orientation and userinterface 2400 is accordingly changed from a portrait display tolandscape display. The placement and positioning of gauges 2414, 2416,2418, 2420, 2422, 2424, 2426 and 2428 are changed so that gauges 2414,2416, 2418, 2420, 2422, 2424, 2426 and 2428 are displayed in ahorizontal alignment instead of a vertical alignment.

Referring to FIG. 24D, after selection of button 2436, user interface2400 is updated to show a setting screen that is customized for eachtype of vehicle data. The settings for the injector pressure can beupdated utilizing units selector 2438, warning level selector 2440, anddefuel level selector 2442.

Unit selector 2438 allows for the selection of the units that are usedto display injector pressure between thousand pounds per square inch(kPSI) and bars. Warning level selector 2440 and defuel level selector2442 operate similar to what is described in FIG. 12 .

Referring to FIGS. 25A through 25D, user interface 2400 is updated aftergraphs button 2408 is selected. Selection of graphs button 2408 triggersthe display of live vehicle data using one or more live scrollinggraphs. The latest vehicle data is displayed at the right most portionof each graph for each selected type of vehicle data. The rest of eachgraph that is being displayed is shifted to the left. This happens foreach update to the live vehicle data that is received from the vehicleby the application running on the client device. In a preferredembodiment, up to eight different types of vehicle data can be displayedwith a graph for each data on a single chart. Each of buttons 2502,2504, 2506, 2508, 2510, 2512, 2514 and 2516 are respectively associatedwith graphs 2532, 2534, 2536, 2538, 2540, 2542, 2544 and 2546. One limitto the maximum data rate of system 22000 is the maximum speed of thecommunication channel between local device 22074 and vehicle device22090, which in a preferred embodiment, is the speed of the CAN bus andis one megabit per second. The data from the CAN bus is consolidatedinto one or more TCP IP packets that are then propagated throughnetworks 22002 and 22004 to pass the data through system 22000.

In order to zoom in on the chart, data is interpolated using at leastone of a selected interpolation method, interpolation methods includingpiecewise constant interpolation, linear interpolation, polynomialinterpolation, and spline interpolation. Piecewise constantinterpolation uses the value of the nearest data value as the currentdata value. Linear interpolation generates straight lines (first degreepolynomials) between adjacent data points to use as the values betweendata points. Polynomial interpolation creates linear functions of usingpolynomials of higher degrees using a plurality of data points. Splineinterpolation uses plurality of low degree polynomials for the differentintervals between the different data points. In a preferred embodiment,linear interpolation is the default interpolation.

Referring to FIG. 25B, the device upon which the application is runninghas been rotated from a portrait orientation to a landscape orientation.The rotation of the device triggers an update to user interface 2400.The update to user interface 2400 rescales each of graphs 2532, 2534,2536, 2538, 2540, 2542, 2544 and 2546 and realigns buttons 2502, 2504,2506, 2508, 2510, 2512, 2514 and 2516 into a single horizontal bar. In apreferred embodiment, each of the graphs 2532, 2534, 2536, 2538, 2540,2542, 2544 and 2546 are reset to show only data that has been receivedafter the update has been triggered.

Referring to FIG. 25C, button 2504 has been selected. Selection ofbutton 2504 brings up the dashboard configuration with selection bar2434 with button 2436 being highlighted to show that button 2504 iscurrently associated with injector pressure. Additionally, each ofbuttons 2508, 2510, 2512, 2514 and 2516 have been interacted with usinga long press to cause user interface 2400 to remove graphs 2538, 2540,2542, 2544 and 2546 that are associated with buttons 2508, 2510, 2512,2514 and 2516 from the display.

Referring to FIG. 25D, user interface 2400 is updated again after thedevice running the application is turned back to a portrait orientation.Graph 2534 is removed from the display.

Referring to FIG. 26 , user interface 2600 is displayed on a clientdevice, such as a technician client device. User interface 2600 is usedto view logged vehicle data or live vehicle data that was transmitted bya vehicle device. User interface 2600 includes a set of vehicle controls2602, 2604, 2606, 2608, 2610, 2612 and 2614, playback chart 2630, and aset of playback controls 2652 and 2656. User interface 2600 displays oneof the logged vehicle data and the live vehicle data as a scrollingdisplay using the set of vehicle controls 2602, 2604, 2606, 2608, 2610,2612 and 2614, the playback chart 2630, and the set of playback controls2652. User interface 2600 displays a graph (2632, 2634, 2636, 2638,2640, 2642, 2644, 2646 and 2648) for each vehicle control that is alinear plot of the information associated with the vehicle control.

Vehicle controls 2602, 2604, 2606, 2608, 2610, 2612 and 2614 eachinclude a checkbox that is used to hide or display a graph associatedwith the vehicle control, a color for the graph, a text field thatidentifies the type of vehicle data, and another text field thatidentifies the units associated with the vehicle data. The set ofvehicle controls can be scrolled left and right so that additionalvehicle controls can be used without each of the vehicle controls beingdisplayed at one time on user interface 2600. Vehicle controls 2602,2604, 2606, 2608, 2610, 2612 and 2614 are respectively associated withgraphs 2632, 2634, 2636, 2638, 2640, 2642, and 2644.

Playback chart 2630 displays graphs 2632, 2634, 2636, 2638, 2640, 2642,2644, 2646 and 2648. Each of graphs 2632, 2634, 2636, 2638, 2640, 2642,2644, 2646 and 2648 are displayed using a color to identify the vehicledata control associated with the graph.

The line for set of playback controls 2652 visually identifies a valuefor each graph on playback chart 2630 for the current playback time. Thegraph automatically scrolls to the left while being played. Playbackchart 2630 can be scrolled independently of the current playback time.Playback control 2654 is used to control whether the logged vehicle datais being played or is paused. Playback control 2656 controls the speedat which the logged vehicle data is being played through playback chart2630. Available speeds include 0.25, 0.5, 1.0, 2.0, and 4.0 times realtime such that it respectively takes, 4 seconds, 2 seconds, 1 second,half a second, and a quarter of a second to play 1 second of vehicledata.

Turning to FIG. 27A, technician interface 2700 allows a technician usinga technician client device to interact with system 22000. In a preferredembodiment, technician interface 2700 is a web page that is hosted by anadministration server and that is displayed using a browser that isrunning on the technician client device.

Technician interface 2700 displays profile view 2702. Profile view 2702includes profile list 2704. Each item in profile list 2704 is associatedwith an ECU profile and includes an identifier, a description, and avalue. The identifier uniquely identifies the original or base profile.The description describes the vehicles for which the profile can beused, including the year, make, model, and engine type. The valueidentifies how many copies of the profile have been made by atechnician.

Each profile displayed in profile list 2704 is selectable and can beedited after being selected. Each copy of a profile can be independentlyedited, stored, and saved.

Turning to FIG. 27B, technician interface 2700 displays ECU editor view2706. ECU editor view 2706 includes profile record list 2708, graph view2710, chart view 2712, information view 2714, and notes view 2716.Profile record list 2708 displays a hierarchical list of the records ofa selected ECU profile. Graph view 2710 displays a user editable graphof the data within a selected record of the selected ECU profile, whichcan be in either two or three dimensions based on the type of data.Chart view 2712 displays a user editable chart of the data within theselected record of the selected ECU profile. Information view 2714displays information about the selected record of the selected ECUprofile, which may not be edited. Notes view 2716 displays notes createdby the technician for the selected record of the selected ECU profile,

Profile record list 2708 includes multiple hierarchical layers ofcategories and leaf nodes and, depending on the vehicle, may containover a thousand categories and leaf nodes. The categories groupcollections of leaf nodes and other categories. Each leaf node is arecord of the selected ECU profile. Data in the record of the leaf nodecan be edited. Selecting either a point on the graph or a cell in thechart highlights both the point on the graph and the cell in the chartand displays adjustment view 2718. Adjustment view 2718 providescontrols for editing the value and identifying whether or not any editedvalue will affect neighboring values through linear or quadraticblending. The blending can be directed to one or both axes. A data pointcan be adjusted by dragging the point on graph view 2710 to a userselected value.

When the data of the selected record of the ECU profile is in threedimensions, graph view 2710 displays the data in three dimensions andchart view 2712 displays the data in two dimensions. The third axis forthe data in chart view 2712 is represented by different shades of color.When the data of the selected record of the ECU profile is in twodimensions, graph view 2710 displays the data in two dimensions andchart view 2712 displays the data in one dimension. The second axis inthis display mode is represented by different shades of color.

Graph view 2710 and chart view 2712 use colors to identify how closeeach data point is to the minimum or maximum value. In a preferredembodiment, minimum values are associated with color shades dominated byblue and maximum values are associated with shades of color dominated byred.

The categories of “ECM [engine control module] MAPS”, “InjectionQuantity”, and “Main Injection” are opened with the leaf node “MainQuantity EOM1” being selected, which is associated with the MainQuantity EOM1 record in the selected ECU profile. The data is threedimensional and is displayed with three dimensions in graph view 2710and is displayed in two dimensions in chart view 2712. Information view2714 indicates that the Main Quantity EOM1 record includes data that isin units of cubic millimeters, has a minimum value of 0, and has amaximum value 160. The Main Quantity EOM1 record is a table thatconverts a desired torque value (in pound feet) and engine RPM to acommanded fuel amount in cubic millimeters. For example, when the amountof torque desired is 221 pound feet and the current engine RPM is 500,then the commanded fuel amount will be 25.1 cubic millimeters. Fuelamounts for torque and RPM values that do not appear in the table areinterpolated using piecewise constant interpolation, linearinterpolation, polynomial interpolation, and spline interpolation.

Turning to FIG. 27C, the categories of “ECM [engine control module]MAPS” and “Axis” are opened with the leaf node and record “Torque axisEOM1” being selected. The data is two dimensional and is displayed withtwo dimensions in graph view 2710 and is displayed in one dimension inchart view 2712. Information view 2714 indicates that the Torque axisEOM1 record is in units of pound feet, has a minimum value of 0, and hasa maximum value 1400. The Torque axis EOM1 record is an axis thatprovides calculated engine torque used in torque to fuel conversion.

Turning to FIG. 27D, the categories of “ECM [engine control module]MAPS” and “Smoke Limitation” are opened with the leaf node and record“Lambda limit REGEN 0” being selected. Information view 2714 indicatesthat the Lambda limit REGEN 0 record includes data that has a minimumvalue of 0 and has a maximum value 2. The Lambda limit REGEN 0 record isa table that converts a cubic millimeter input and engine RPM to alambda value. For example, when the cubic millimeter input is 50 and thecurrent engine RPM is 100, then the lambda value is 0.90. Lambda valuesfor cubic millimeter input and RPM values that do not appear in thetable are interpolated using piecewise constant interpolation, linearinterpolation, polynomial interpolation, and spline interpolation.

Turning to FIG. 27E, the categories of “ECM MAPS”, “Injection Timing”,and “Pilot Injection” are opened with the leaf node and record “Pil.1Timing EOM0/Temp.1/Conf.2” being selected. Information view 2714indicates that the Pil.1 Timing EOM0/Temp.1/Conf.2 record includes datathat is in units of degrees before top dead center (TDC), has a minimumvalue of -10, and has a maximum value 40. The Pil.1 TimingEOM0/Temp.1/Conf.2 record is a table that converts a torque value (inpound feet) and engine RPM to an injection timing value. For example,when the amount of torque desired is 221 pound feet and the currentengine RPM is 750, then the injection timing will be 11.7 degrees beforetop dead center.

Turning to FIG. 27F, the categories of “ECM MAPS” and “Injection Events”are opened with the leaf node and record “Max. Injection pulses vs. RPM”being selected. Information view 2714 indicates that the Max. Injectionpulses vs. RPM record is in units of pulses, has a minimum value of 0,and has a maximum value 5. The Max. Injection pulses vs. RPM recordidentifies the maximum number of injection pulses that are allowed basedon a specific engine RPM.

Turning to FIG. 27G, the categories of “ECM MAPS” and “AcceleratorPedal” are opened with the leaf node and record “Accelerator Pedaltable” being selected. Information view 2714 indicates that theAccelerator Pedal table record includes data on the “y” axis that isindicative of percentage of pedal displacement, has a minimum value of0, and has a maximum value 100. The Accelerator Pedal table record is atable that converts an actual accelerator pedal position (as apercentage) and engine RPM to an interpreted accelerator pedal positionshown on the “z” axis. For example, when the actual position is 80percent and the current engine RPM is 1000, then the interpretedposition will be 52 percent.

Turning to FIG. 27H, the categories of “TCM [transmission controlmodule] MAPS”, “Shift Points”, and “2-3 Shift” are opened with the leafnode and record “2-3 Up-shift Main” being selected. Information view2714 indicates that the 2-3 Up-shift Main record is in units of outputshaft speed (OSS), has a minimum value of -10, and has a maximum value5000. The 2-3 Up-shift Main record identifies the shift point thresholdbased on throttle position and shaft speed when shifting from 2nd gearto 3rd gear. The minimum shift point is with a shaft speed of 575 RPMand the throttle position at 6% and the maximum shift point is with ashaft speed of 1288 RPM and the throttle position at 75%. Outside ofthese constraints, up shifting from 2nd to 3rd gear will not beperformed.

Turning to FIG. 27I, the categories of “TCM MAPS”, “Desired Slip”, and“3-4 Shift” are opened with the leaf node and record “Target total slipfor 3-4 shift” being selected. Information view 2714 indicates that theTarget total slip for 3-4 shift record includes data that is inmilliseconds, has a minimum value of 0, and has a maximum value 750. TheTarget total slip for 3-4 shift record is a table that identifies atarget slip time for a shift based on torque (in pound feet) and engineRPM. For example, when the torque is 300 percent and the current engineRPM is 2000, then the target desired slip is 440 milliseconds.

Turning to FIG. 27J, the categories of “TCM MAPS”, “Line Pressure”, and“2-1 Shift” are opened with the leaf node and record “Press. 2M-1MONCOMING” being selected. Information view 2714 indicates that thePress. 2M-1M ONCOMING record includes data that is in pounds per squareinch (PSI), has a minimum value of 0, and has a maximum value 350. ThePress. 2M-1M ONCOMING record is a table that identifies the 2-1 oncoming start pressure, which is the starting point for pressure beforeadaptive changes, and is based on engine RPM and torque (in pound feet).For example, when the RPM is 2250 and the torque is 50 pound feet, thenthe start pressure is 111 pounds per square inch.

Turning to FIG. 27K, the “TCM MAPS” category is opened with the leafnode and record of “Diagnostics” being selected. Information view 2714indicates that the Diagnostics record allows for enabling or disablingdiagnostic trouble codes (DTCs). Chart view 2712 includes a list of thediagnostic codes that can be enabled or disabled. In a preferredembodiment, selection of one of the diagnostic codes causes informationview 2714 to display descriptive information about that diagnostic code.

Referring to FIG. 28 , local device 22074 is a system that incorporatesseveral systems, devices, controllers, boards, modules, and interfaces.Local device 22074 includes controller 2802 that runs one or moreapplications so that local device 22074 can interact with system 22000.In a preferred embodiment, controller 2802 is an i.MX 6 seriesmicrocontroller.

LEDs 2824 are connected to GPIO pins 2826. In a preferred embodiment,LEDs 2824 include a red LED to indicate and error condition and a blueLED to indicate short range wireless connectivity status. GPIO pins 2826can be activated using pulse width modulation (PWM) to control theintensity of LEDs 2824.

Debug header 2828 provides the physical interface for several ports oncontroller 2802 that are used for debugging purposes. The debuggingports include the set of interfaces 2830, which includes a JTAGinterface, serial port interfaces (UART1 and UART2), one or more generalpurpose input output (GPIO) pins, and a reset pin of controller 2802.The JTAG interface allows for connecting to external devices that areused to debug local device 22074. The serial port interfaces allow forconnecting to external chips and peripherals including GSM module 2806,which is connected to UART2. The usage of the GPIO pins areprogrammatically defined to either read or write data to or fromcontroller 2802. The reset pin is used to cause controller 2802 to resetitself.

Connector harness 2832 provides the physical connection for several ofthe interfaces provided by controller 2802, including the UART2interface, one or more GPIO pins, the CAN bus interfaces, and the USBinterfaces. Connector harness 2832 provides the connections to GSMmodule 2806 and power controller 2818 for controller 2802.

GPIO pins 2834 are programmatically controlled. GPIO pins 2834 allowcontroller 2802 to export data to or import data from other devicesattached through connector harness 2832.

First USB port 2836 and second USB port 2838 allow for connectivity todevices and peripherals outside controller 2802. Second USB port 2838 isconnected through connector harness 2832 to GSM module 2806 to allow forcommunication between and control of GSM module 2806 by controller 2802.

GSM module 2806 includes circuits, modules, and printed circuit boardsthat, when driven and operated by controller 2802, allow local device22074 to connect to and exchange data with mobile network 22004.

Interfaces 2808 and 2810 respectively connect to CAN interface circuits2812 and 2814, respectively. Interfaces 2808 and 2810 are used bycontroller 2802 to interact with one or more CAN buses through an OBDport of the vehicle to which local device 22074 is attached. CANinterface circuitry 2814 includes the analog multiplexer, as describedin FIG. 21 , to allow CAN interface 2810 of controller 2802 to operatewith the vehicles of different manufacturers that use different pinoutsfor the location of the second can interface in the OBD port connector.CAN interface circuits 2812 includes the physical connectors betweeninterface 2808 of controller 2802 and connector harness 2832.

Set of interfaces 2816 connects controller 2802 to power controller2818. Power controller 2818 controls power supply network 2840 and thepower on boot sequence for local device 22074. Power supply network 2840includes several power rails of different voltages to provide Power tothe devices and chips within local device 22074.

In a preferred embodiment, power controller 2818 is an over-the-airconfigurable power controller operating independent of the mainprocessor. Power controller 2818 is updateable by controller 2802through the use of a serial communication interface of the set ofinterfaces 2816, allowing cloud-based updates to the integrated circuitof power controller 2818. The integrated circuit of power controller2818 is used for customizing multiple power sequencing, power saving,and security functions, including but not limited to, dynamic powerthrottling and disabling the local device if unauthorized ornon-licensed use is detected.

Set of interfaces 2820 connects to one or more modules 2822 that provideone or more wireless network connections. In a preferred embodiment,module 2822 provides connectivity to wireless area networks using Wi-Fiprotocols and to personal area networks using Bluetooth protocols.Oscillator 2854 is a reference oscillator for module 2822. Oscillator2854, in a preferred embodiment provides about a 32 kilohertz referencesignal to module 2822.

Module 2822 is connected to antenna 2856 and to antenna 2858. Antenna2856 is a surface mount device (SMD) antenna that is used for Bluetoothprotocol communications. Antenna 2858 is also an SMD antenna, but isused for Wi-Fi protocol communications. In a preferred embodiment,antenna 2856 and antenna 2858 are the same type of antenna mounted atdifferent positions o the board on which module 2822 is mounted toreduce interference.

Multimode DDR controller (MMDC) 2842 of controller 2802 connects tomemory 2844. In a preferred embodiment, memory 2844 is DDR3 memory andis the random access memory used by controller 2802 to execute programsand instructions for local device 22074.

General purpose media interface 2846 allows for connection of controller2802 with external flash memory, such as memory 2848. In a preferredembodiment, memory 2848 is a NAND flash memory that provides persistentstorage for the programs and data executed and used by controller 2802.

Secure digital (SD) interface 2850 of controller 2802 provides forconnecting removable secure digital media to and from local device 22074through SD card holder 2852.

Referring to FIG. 29 , a state diagram 2900 of different states of apreferred embodiment of the local device is depicted.

In wait state 2906, the local device is powered up and waits for furtherinput.

Transition 2908 to mode select state 2910 occurs with a user selectionof a mode of the local device from a GUI display. Mode select state 2910includes a Tune Control Mode/function of the local device, as will befurther described. Transition 2912 returns the local device to waitstate 2906.

Transition 2914 to output control mode state 2916 includes an OutputControl Mode/function of the local device, as will be further described.Transition 2918 returns the local device to wait state 2906.

Transition 2920 to ELD state 2922 includes an ELD Mode/function of thelocal device, as will be further described. Transition 2924 returns thelocal device to wait state 2906.

Transition 2926 to live data mode 2928 includes live data mode/functionof the local device, as will be further described. Transition 2930returns the local device to wait state 2906.

Transition 2932 to third-party proxy control mode 2934 includes thethird-party proxy functions of the local device, as will be furtherdescribed. Transition 2936 returns the local device to wait state 2906.

Referring now to FIGS. 30A, 30B, 30C and 30D, mode select state 2910, isfurther described. At step 3002, mode select state 2910 is selected. Atstep 3004, the local device sends a message to the vehicle controller,confirming the vehicle type. At step 3006, a set time for receiving aresponse from the vehicle controller is monitored. If a response is notreceived within the set time, then the local device times out at step3008 and returns to step 3002. If a response is timely received, thenthe method proceeds to step 3010. At step 3010, the message from thevehicle controller is masked, including message header, frameparameters, and Serial IDs (SIDs). The SIDs include, but are not limitedto, RPMs, gear and transmission parameters (e.g., temperature), ignitionkey position, throttle position, and coolant temperature.

At step 3012, sufficient memory is reserved for performing the tunemodifications. A buffer may be used, or an array of sufficient size isdefined, for receiving a SOFT map. At step 3016, PID variables aredefined in memory for performing tune modifications.

At step 3018, a CAN configuration file is retrieved from the vehiclecontroller, which include VIN, year, and ECU and TCU part and serialnumbers.

At step 3020, a year of the vehicle is compared to a predetermined year.For example, if the predetermined year is 2012 and the vehicle year isgreater than or equal to 2012, then the method moves to step 3022. Atstep 3022, one or more power levels are retrieved from a JSON messageand are used to adjust the ECU and/or the TCU in the vehicle. The methodthen ends at step 3023. In this example, if the vehicle year is lessthan 2012, then the method moves to step 3024, as shown in FIG. 30B.

Referring then to FIG. 30B, at step 3024, a SOTF map is read from thecalibration file included in the JSON message. Power levels, partnumbers, VIN, and serial numbers are also read at step 3024. In apreferred embodiment, the data read at step 3024 is stored in the CPUregister using a ring or FIFO buffer.

At step 3026, the data read at step 3024 is checked to ensure itincludes an ECU part number. If so, then at step 3027, the ECU partnumber is stored and the method moves to step 3028. If not, then themethod proceeds directly to step 3028.

At step 3028, the data read at step 3024 is checked to ensure itincludes an ECU serial number. If so, then at step 3029, the ECU serialnumber is stored and the method moves to step 3030. If not, then themethod proceeds to step 3030.

At step 3030, the data read at step 3024 is checked to ensure itincludes a TCU part number. If so, then at step 3031, the TCU partnumber is stored and the method moves to step 3032. If not, then themethod proceeds to step 3032.

At step 3032, the data read at step 3024 is checked to ensure itincludes a TCU serial number. If so, then at step 3033, the TCU serialnumber is stored and the method moves to step 3034. If not, then themethod proceeds to step 3034.

At step 3034, the data read at step 3024 is checked to ensure that a VINis present. If so then at step 3035 the VIN is stored and the methodmoves to step 3036. If not, then the method moves to step 3036.

At step 3036, the data read at step 3024 is checked to ensure itincludes an SID. If not, then at step 3037, an “Error” message isprovided and the method ends at step 3038. If so, then the methodproceeds to step 3039, as shown in FIG. 30C.

Referring then to FIG. 30C, at step 3039 the ignition status of thevehicle is checked. If it is “ON”, then at step 3040 a “Turn engine off”message is sent to the display and the method returns to step 3039. Ifthe ignition is “OFF”, then at step 3044 a “Turn ignition to ONposition” message is sent to the display and the method moves to step3046.

At step 3046, the vehicle status is determined. The vehicle statusindicates if the vehicle is running properly and whether or not thereare any outstanding DTCs. If the vehicle is not running properly (i.e.,status != Normal), then at step 3048, the Tune Control mode ends (i.e.,no modifications are made) and the system returns to a wait state. Step3048 may also include sending an error message, to the display. If thevehicle is running properly then the method proceeds to step 3050.

At step 3050, the method parses the PIDs that were read at step 3018.The PIDs that are parsed include, but are not limited to, engine controlmodule (ECM) voltage, ambient air temperature, engine oil temperature,intake air temperature, boost parameters, rail pressure desired, railpressure actual, transmission line pressure desired, barometricpressure, variable geometry turbo position actual, variable geometryturbo position desired, exhaust gas recirculation valve position actual,exhaust gas recirculation valve position desired, mass air flow, dieselparticulate filter soot load, exhaust pressure, main injector eventtiming, transmission shaft output speed, torque converter slip, exhaustgas temperature, and main injection quantity desired. If a value for thePID is not provided in the message, the parsing moves to the next PID(e.g., break). If the value for the PID is in the message, then thevalue is stored in a data structure (e.g., array, lookup table, definedvariable, etc.). The method then moves to step 3052, shown in FIG. 30D.

Referring then to FIG. 30D, at step 3052 a new CAN configuration file iscreated, including checking CRCs against stored CRCs (e.g., thoseinitially received from the vehicle controller). Only the modified CRCsare updated in the new configuration file.

At step 3054, a determination is made as to whether or not prior systemfailures have occurred.

If so, then at step 3055, the method performs a reflash recoveryoperation. The reflash recovery operation may include obtaining anappropriate file for the recovery, reading data from the file,downloading and/or updating the bootfile, erasing a sector of theappropriate module, writing data to the sector (e.g., for ECM and/orTCM), performing necessary iterations for other sectors, and resettingthe module. The method then moves to step 3056. If not, then the methodmoves to step 3062.

At step 3056, a determination is made as to whether or not the reflashwas successful. If not, the method moves to step 3058. If so, the methodmoves to step 3062.

At step 3058, the method reports an unsuccessful refresh. Step 3058 mayinclude providing a visual alert, audio alert, or other indication of anunsuccessful function, and an indication of where the error occurred. Atstep 3060, the method ends the operation of the Tune Control mode.

At step 3062, the RPM of the vehicle engine is checked. If the RPM valueis zero, then the method moves to step 3064. At step 3064, the methodwaits a predefined short time period and then returns to step 3054. Step3064 is only repeated a finite predetermined number of times before themethod times out. If the RPM value is greater than zero, then at step3066 the method implements the power level modifications in the SOTFmap.

At step 3068, DTCs are adjusted according to the newly implemented powerlevels and SOTF map. At step 3070, the Tune Control mode ends and thesystem returns to a wait state. Step 3070 may further include providinga visual alert, audio alert, or other indication of a successfulcompletion of tuning modifications.

Referring now to FIG. 31 , Output Control Mode state 2916 is furtherdescribed. Output Control Mode state 2916 includes volume control (e.g.,increase, decrease, mute), communication output control (e.g., Wi-Fioutput ceased, re-started, or paused; Bluetooth output ceased,re-started, or paused), device settings such as delay time between abeacon alert and beacon implementation, as will be further described.Alert control such as the form and type of alerts that will be displayedon the client device security prompt output, device output control(e.g., whether or not mobile devices will be allowed or restricted fromusing the local device as an internet access point), and combinationsthereof.

At step 3102, the client device displays a menu of the output controloptions that are adjustable. At step 3104, the specific output isselected. At step 3106, a determination is made as to whether or notdual adjustment levels are present. If so, then at step 3108, theadjustment is made by way of the user touching the display. If not, thenthe method moves to step 3112. At step 3110, the output control modeends. Step 3110 may further include a delay before the display of outputcontrol closes, enabling the user to see the selection that occurred.

At step 3112, if the output control selected from the menu at step 3104has a multiple adjustment levels associated with it, then the clientdevice displays the multiple adjustment levels. At step 3114, at leastone of the multiple adjustment levels is selected. For example, ifvolume control is selected at step 3104, then a sliding GUI element mayenable the user to slidingly adjust the volume level of alerts generatedby the local device from multiple different volume levels. At step 3116,after making the adjustment to the desired level among the multi-leveloutput control, the Output Control Mode ends.

Referring then to FIGS. 32, 33A - 33E and 34 , ELD state 2922, isfurther described. ELD mode includes a query for one or more of arouting code, an email address, or other additional input may bereceived from a safety officer or a motor authority representative.Additional input during the ELD mode may also include a report periodrequest. For instance, the safety officer may be interested in RODS forthe last 24 hours, the last week, the last six months, or anotherspecified period of time. Receipt of the report period input may enableadditional functions such as logged data retrieval from the localdevice, the system server, or a combination thereof. The additionalinput during ELD mode may also include acceptable operator annotations.For example, an operator may be able to add a comment for a specificRODS report or entry. For instance, the local device may prompt theoperator, via client device, to enter waiting time information, breakinformation, or unassigned driver information.

Referring first to FIG. 32 , method 32000 shows several steps utilizedby system 22000 to perform ELD mode of the local device. The systemacquires logged data for, in a preferred embodiment, an administrativeofficial such as a motor authority representative or safety officer, whouses the system with customer client device 22060 or with a motorauthority client device, to display logged data, display live data, andsend RODS or other vehicle/safety reports using cloud services providedby administration server 22008. For example, a motor authority officialcan ask an operator (i.e., customer) for vehicle data logs for aDepartment of Transportation (DOT) inspection. The operator usescustomer client device 22060 to connect to vehicle device 22090 throughsystem 22000. The motor authority official reviews logged vehicle dataand/or live vehicle data that is provided through system 22000. System22000 generates an on-screen inspection, based on the vehicle data andmotor authority (e.g., Federal Motor Carrier Saftey Administration(FMCSA)) rules and regulations, including alerts for logs that may notbe fully compliant with the rules and regulations. The motor authorityofficial reviews the vehicle data and otherwise performs the on-screeninspection. The official then may instruct system 22000 to transfer thevehicle data to the motor authority client device or third-party server22020. An example is a motor authority server.

At step 32020, vehicle data is generated by vehicle device 22090. Thevehicle data includes data, information, and code from one or moresensors, systems, and devices that are connected to vehicle device22090.

At step 32022, vehicle device 22090 sends vehicle data, to local device22074.

At step 32024, local device 22074 generates logged vehicle data. Thelogged vehicle data is a set of the data that includes one or more ofoff duty time, sleeper berth time, driving time, on-duty not drivingtime, annotations, driver’s location description and modifications,comments, commercial motor vehicle power unit number, mileage records,trailer number(s), shipping document number(s), driver hours of service(HOS) records, RODS, and combinations thereof. Step 32024 furtherincludes encapsulating the logged vehicle data and forming packets fortransmission. Step 32024 may further include filtering each section of amessage frame, such as with an XOR operation, a parity check, or a deltaoperation, to determine if each of the required sections includes data.If the filter indicates that each of the required sections includesdata, then the logged data may represent a certified log. The requiredsections include, but are not limited to, the calendar day for whichvehicle data logs were created, a driver ID for the operator duringcreation of the ROD.

Step 32024 may further include sorting the data for the vehicle logs.The data may be sorted according to day, time frame (i.e., period), andtransaction for the logged vehicle data. The timeframe identifies thelength of a window of time for vehicle data, such as the previous 24hours of vehicle data. The transaction identifies how the encapsulated,packetized, or logged data should be handled (e.g., displayed accordingto a display protocol, transmitted via email, transmitted via localconnection such as Bluetooth, etc.) by local device 22074 before beingdiscarded and includes, in a preferred embodiment, options for datacompression, data transmission, and file transfer comments.

At step 32026, a link is established between local device 22074 andcustomer client device 22060. For example, local device 22074 may beestablished as a Wi-Fi access point, through which customer clientdevice 22060 may access the internet as well as communicate withadministration server 22008. By way of another example, the link may bea short-range, Bluetooth connection between local device 22074 andcustomer client device 22060.

At optional step 32028, a link may be established between customerclient device 22060 and customer client device 22060. The optional linkmay allow for local, short-range transfers, such as Bluetooth orpeer-to-peer (P2P) data transfers.

At step 32030, a logged vehicle data request is generated by customerclient device 22060. Step 32030 may further include generating a periodrequest or including additional information with the request such as thetime frame for which the logged data is requested. Step 32030 mayfurther include prompting the operator for a routing code (e.g.,provided by a safety officer or motor authority representative), adestination IP address, and/or other transactional information.

At step 32032, customer client device 22060 sends the logged vehicledata request, which is received by the local device 22074. At optionalstep 32034, a notification is sent from customer client device 22060 toadministration server 22008 of the logged data request.

At optional step 32036, customer client device 22060 generatesauthorization for local device 22074 to transfer logged data to a linkedmotor authority client device. At step 32038, the authorization is sentto local device 22074.

At optional step 32040, the logged vehicle data request may be generatedby technician client device 22046. At step 32041 the technician clientdevice may also include prompting the administrative server for arouting code or other transactional information.

At optional step 32042, technician client device 22046 sends the loggedvehicle data request, which is received by local device 22074. Atoptional step 32044, a notification is sent to administration server22008 of the logged data request.

At step 32046, administration server 22008 identifies the devicesassociated with the request. For example, administration server 22008may identify customer client device 22060, local device 22074, and/ortechnician client device 22046 associated with the request.

At step 32048, the logged vehicle data response is generated. At step32050, the logged vehicle data is filtered by local device 22074. Thelogged vehicle data is filtered based upon the contents of the loggedvehicle data request that was initiated with either customer clientdevice 22060 or technician client device 22046. For example, if thetimeframe in the logged data request is the last 24 hours, then thelocal device filters the logged vehicle data such that only the last 24hours of logged data is prepared to be sent in the response.

At step 32051, the local device provides a certified log of vehicledata, as will be further described.

At step 32052, local device 22074 sends the logged vehicle dataresponse, which is received by customer client device 22060. At step32054, customer client device 22060 stores and displays the loggedvehicle data from the logged vehicle data response. At optional step32056, customer client device 22060 sends the logged vehicle dataresponse to third-party server 22020.

At optional step 32058, local device 22074 sends the logged vehicle dataresponse to technician client device 22046. At optional step 32060,technician client device 22046 displays the logged vehicle data responsefor the on-screen inspection.

Referring to FIGS. 33A and 33B, after selection of the appropriateapplication from customer client device 33000, a user may select an ELDmode or function from a list of modes/functions of local device 33002.Upon selection of an ELD mode, user interface 33005 displays options foraccessing logged vehicle data that is received from local device 33002.The data displayed with user interface 33005 can be directly from localdevice 33002, can be from customer client device 33000 and displayed ontechnician client device 33006, or it may be from an administrationserver that received the data after the data was transmitted from localdevice 33002. User interface 33005 includes several user interfaceelements.

Menu button 33007 (further described below) is a menu button that, onceselected, brings up a main menu. The main menu allows the user to selectdifferent functions within the application.

User interface button 33008 (e.g., element/button of capacitive-touchdisplay) has been selected to send logs to technician client device33006 or a mobile authority server (e.g., FMCSA). GUI 33010 isconfigured to receive transaction information, such as a routing code,with user interface element 33012. In some embodiments, user interfacebutton 33008 is a flat navigation element, meaning that upon selection,relatively few additional GUIs will be necessary to obtain the desiredfunction (e.g., one GUI 33010 used to send logs with button 33013).

Referring to FIGS. 33A and 33C, user interface button 33014 has beenselected to conduct a second function of the application (e.g., anon-screen inspection). GUI 33016 is configured with multiple menubuttons 33018. In some embodiments, multiple menu buttons 33018 are flatnavigational elements to access a two- or three-level hierarchy of datarelated to the selected function, such as the on-screen inspection. Forexample, the selection of a first menu button of multiple menu buttons33018 may result in a display of dates associated with certified logs.The user interface element Un-ID’d LOGS is shown at 33035. Userinterface element 33035 includes certified check boxes such as 33034 and33036. If the boxes are checked, the logs are certified. If they are notchecked, the logs are not certified.

Button 33020 is a user interface element that, upon being selected,shows vehicle data associated with a specific, certified log. Forexample, each of the dates displayed in GUI 33016, after selection ofbutton 33018, may be an interactive user interface element providingaccess to respective, associated certified logs and related data. Thedates of GUI 33016 may be displayed together as a scrollable GUI.

Referring to FIGS. 33C and 33D, upon selection of button 33020, GUI33022 is displayed. GUI 33022 may include additional menu buttons. Forexample, a first menu button 33024 may be selected to displaybroad-level data and interpretations pertaining to a specific, certifiedlog. The broad-level data and interpretations may include Records ofDuty Status (RODS), graphical representations, playback charts (e.g.,for live data creating current RODS or a current ELD log), changes induty status, hours, associated mileage, name of the city/town, Stateabbreviations, driver ID, and combinations thereof. For example, a graphview 33025 may display RODS information and hours related thereto. Asecond menu button 33026 may be selected to obtain additionalinformation for the specific, certified log. For example, the certifiedlog for Wednesday, January 31, may include additional relatedinformation such as fuel receipts, toll receipts and records, tripreports, bills of lading, verification documents, and combinationsthereof.

Referring to FIG. 33E, chart view 33030 of GUI 33022 may be used inplace of, or together with, graph view 33025. For example, a togglebutton (not shown) may be used to switch between graph view 33025 andchart view 33030. Each of graph view 33025 and chart view 33030 may bescrollable displays, which may be scrolled to obtain additionalinformation about the displays or information presented therein. In someembodiments, GUI 33022 may include an input prompt for annotations,which are received according to a specified format (e.g., “Day,Comment”).

A zoom feature may be associated with the graphical representation andother features of the GUIs discussed in FIGS. 33A - 33E. In such cases,appropriate data interpolation may be used.

Referring to FIG. 34 , a method of generation of a certified log asshown in step 32051, will be further described. The generation of thecertified log may be processed based on format, content, or associatedmetadata. At step 3402, local device 22074 makes a query regarding dateand time. The date and time is provided by a local clock within localdevice 22074, or a clock within vehicle device 22090, and stored in afirst array. At step 3404, local device 22074 makes a query regarding adriver ID. If the driver ID is entered through a GUI of local device22074, then the data is stored in a second array. If the driver ID isnot entered, then the method proceeds to step 3406 and queries the ECUfor any data required for at least one ROD. The data resulting from step3406 includes, but is not limited to, RPMs greater than zero, period oftime RPMs are greater than zero, RPMs greater than a specified idlevalue, period of time RPMs are greater than the specified idle value,gear value, and period of time associated with gear value.

At step 3408, local device filters and sorts the data according to date,time, and preprogrammed classifications. The preprogrammedclassifications include, but are not limited to, ‘vehicle driving’,‘vehicle idling’, and ‘vehicle off’. Step 3408 further includesperforming a data calculation or data check, such as a simple paritycheck or XOR operation, to determine if each required field has contentwithin it.

At step 3410, the results of step 3408 are checked to determine if eachrequired field is populated with data. At step 3412, if each requiredfield is populated with data, then a “certified” log is generated. Anindication is provided on user interface GUI 33016 that a log is“certified”. At step 3415, the method then ends.

At step 3410, if each required field is not populated with data (e.g.,driver ID is missing), then a log may be created by local device, but itis not “certified”. At step 3414, an indication is provided on userinterface GUI that a log is not certified. At the same time, if one ormore entries are significantly different from expected value(s), such asby two or more parameters, e.g., driver ID is missing and the calendarday has been altered, then an alert is generated. The alert iscommunicated to the administrative server. At step 3415, the method thenends.

Referring again to FIGS. 5A - 16A and the accompanying text, live datamode 2928 is described. For example, if live data mode 2928 is selected,then the local device is configured to provide live data from any of themany vehicle computers, sensors, and detectors to a display of theclient device.

Referring then to FIG. 35 , third-party proxy mode 2934 will be furtherdescribed.

In third-party proxy device mode, the third-party proxy device can, uponexecuting method 3500, honk the horn, turn on the lights, set interiorHVAC controls or execute other functions which alter the performance orappearance of the vehicle to which the vehicle controller is connected.

Method 3500 includes system server 102 in communication with third-partyproxy device 3501. In a preferred embodiment, third-party proxy device3501 includes smart phone running an appropriate application to generatethe functions shown.

At step 3510, third-party proxy device 3501 generates a proxy request. Aproxy request includes a set of vehicle functions which third-partyproxy device 3501 wishes to execute on vehicle device 114. At step 3512,the proxy request is sent to system server 102. At step 3514, systemserver 102 logs the proxy request and identifies the appropriate vehicledevice 114 and associated local device 112 and associated client device110. At step 3516, system server 102 sends the proxy request to clientdevice 110. At step 3518, client device 110 authorizes the proxyrequest. At step 3520, client device 110 sends a proxy authorization tosystem server 102. At step 3522, system server 102 logs the proxyauthorization. At step 3524, system server 102 sends the proxyauthorization to third-party proxy device 3501. At step 3526,third-party proxy device 3501 generates a set of proxy vehicleinstructions. At step 3528, third-party proxy device 3501 sends theproxy vehicle instructions to client device 110. At step 3530, clientdevice 110 approves the proxy vehicle instructions. At step 3532, clientdevice 110 sends the proxy vehicle instructions to local device 112. Atstep 3534, local device 112 formats the proxy instructions for thevehicle device. At step 3536, local device 112 sends the formatted proxyvehicle instructions to vehicle device 114. At step 3538, vehicle device114 executes the formatted proxy vehicle instructions.

Referring to FIG. 36 , implementation of a security function withinlocal device 112 will be further described.

Method 3600 includes local device 112 in communication with powercontroller 2818. In a preferred embodiment, vehicle device 114 includesan over-the-air configurable power controller operating independentlyfrom the main processor of local device 112. An example is shown in FIG.28 .

At step 3610, client device 110 starts the mobile device application. Atstep 3612, local device 112 powers on and boots up. At step 3614,vehicle device 114 boots up. At step 3616, vehicle device 114 retrievesa version number from memory. At step 3618, the vehicle device sends theversion number to local device 112. At step 3619 local device 112 storesthe version number. At step 3620, the application on client device 110generates a request for the version number. At step 3622, client device110 sends the request for the version number to local device 112. Atstep 3624, local device 112 retrieves the version number from memory. Atstep 3626, local device 112 sends the version number to client device110. At step 3628, client device 110 retrieves authentication data. Theauthentication retrieved includes the power controller version number, acode number, and a serial number of the local device. In a preferredembodiment, the code number is produced by an algorithm that providesindependently repeatable results based on a seed number. In a preferredembodiment, the algorithm may be a cryptographic cypher based on chaostheory, a serial 256-bit function, or another non-linear function. Atstep 3630, client device 110 sends the authentication data to systemserver 102. At step 3632, system server 102 checks the authenticationdata against stored authentication data. In one embodiment, theauthentication data is one or more of version number, serial number andcode number. At step 3634, system server 102 generates an authenticationresponse including an update. The authentication response includes anauthorization response or a non-authorization response, and the updateincludes an update for one or more of the mobile application on clientdevice 110, local device 112, and vehicle device 114. At step 3636,system server 102 sends the update to client device 110. At step 3638,client device 110 receives the update, and optionally installs theupdate for the mobile application. At step 3640, client device 110 sendsthe update to local device 112. At step 3642, local device 112 receivesthe update and optionally installs the update. At optional step 3644,local device 112 reboots. At step 3646, local device 112 sends theupdate to vehicle device 114. At step 3648, vehicle device 114 receivesand installs the update. If the update includes an authorizedauthentication response, then vehicle device 114 receives and installsthe update at step 3648. At optional step 3650, power controller 2818reboots. However, if the update includes a non-authorized authenticationresponse, vehicle device 114 receives and installs the update, but theupdate causes vehicle device 114 to generate one or more power controlsignals. The one or more power control signals cause at least one ofvehicle device 114 and local device 112 to shut down or enter aninsecure mode. In a preferred embodiment, the power control signalsimplement a power throttling or security function including, but notlimited to, reducing power to one or more integrated circuits of localdevice 112, performing a hardware interrupt, a circuitry reset,accessing one or more fuses of an electrical fuse array, receiving acold reset negative logic input, or a combination thereof.

Referring to FIG. 37 , setup of J2534 compliant local device 112 will bedescribed as process 3700.

At step 3702, user opens application 111 on client device 110. At step3704 a user account is created by entering personal information, such asname, email address and telephone number, and vehicle information, suchas VIN, year, make, and model. At step 3708, the calibration writerserver creates an account based on information from the system server.The calibration writer server includes account information such as name,address, email address, and submit computer Cal/Pid. At step 3710,calibration writer server determines a set of operating systemparameters which includes programming information, such as communicationprotocol and look up tables for the onboard controller. At step 3712,the parameters are submitted to system server 102. At step 3714, systemserver 102 stores the parameters and the account implementation. At step3716, the database is updated by the system server with the accountinformation and system parameters. At step 3718, the system serveruploads the system parameters to client device 110 via a wirelessnetwork.

At step 3720, client device 110 stores the system parameters. At step3722, client device 110 establishes a wireless connection with localdevice 112 through Bluetooth or Wi-Fi. At step 3724, user initiatesdevice setup. At step 3726, client device 110 uploads system parametersto local device 112. At step 3728, local device 112 stores systemparameters. In step 3730, local device 112 establishes a communicationconnection with vehicle device 114 through an OBD II port utilizing thecommunication protocol determined from the system parameters. In apreferred embodiment OBD II port is a J1962 connector. At step 3732,vehicle device 114 acknowledges the connection. At step 3734, a messageis generated containing vehicle device 114 details, such as softwareversion numbers, automotive controller and engine control unit modelsand serial numbers.

At step 3736, acknowledgement and details are sent to local device 112.At step 3738, the details are stored in local device 112. At step 3740,details are transmitted to client device 110. At step 3741, clientdevice stores details. In step 3742, the details are relayed to systemserver 102. At step 3744, the system server stores vehicle device 114details. At step 3746, system server 102 updates database 106.

In step 3748, application 111 displays potential settings and systemoperation parameters for vehicle device 114 on client device 110. Atstep 3750, user selects desired options which are received by the clientdevice. In step 3752, the selected parameters are uploaded to localdevice 112. At step 3754, the selected parameters are stored on localdevice 112. In step 3756, local device 112 uploads the parameters tovehicle device 114. In step 3758, vehicle device 114 logs theparameters. At step 3760, the parameters are implemented. At step 3762,the implementation of the parameters is acknowledged. At step 3764,acknowledgement is sent to local device 112. In step 3766, theacknowledgement is reported to client device 110. At step 3768, clientdevice 110 displays the status of vehicle device according to the setparameters.

Referring to FIG. 38 , administrative process 3800 for updating theJ2534 application files is described.

At step 3802, administrator user opens cloud-based web application onadministrator device 22032. In step 3804, logon credentials arereceived. At step 3806, administrator logon request is submitted toadministration server 22008. At step 3808, administration server 22008logs the request. At step 3810, the server verifies the administratorlogon credentials. If the logon credentials are incorrect, then at step3812, a denial is generated. At step 3814, the denial is thentransmitted to administrator device 22032. If the logon credentials arecorrect, then at step 3816, administration server 22008 approves thelogon request. At step 3818, administration server transmits theadministrator web application to administrator device 22032.

At step 3819, administrator web application is displayed. At step 3820,the J2534 Application tab is chosen. At step 3822, a selection to add anew version of J2534 Application 126 is received. An example of the GUIscreen displayed is shown in FIG. 42 . In step 3824, a selection of adesired application file to upload is received. The application fileconsists of an installation file for J2534 application 126 and the DLLfile for the local device. At step 3826, private comments on the versionbeing uploaded are entered. In step 3828, release notes on theapplication version are received and made viewable by technicians andthird parties. In step 3830, administrator selects the “Add” graphicaldepiction of a button. At step 3832, administrator device 22032 uploadsthe new version of the J2534 Application. In step 3834, the new versionof the J2534 Application is transmitted to administration server 22008.At step 3836, the new version is stored on administration server 22008.At step 3838, the new version of the J2534 Application is transmitted tosystem server 102. In step 3840, system server 102 stores the newversion.

Referring to FIG. 39 , setup of a receiving device for the remoteanalysis and reprogramming of vehicle device 114 will be described asprocess 3900. While in this figure the receiving device is shown astechnician device 124, in alternate embodiments, the receiving devicecan be either technician device 124, or third-party device 130.

At step 3902, a request is made for access to OEM API 128 for a vehiclemanufacturer. At step 3904, an account is created with the manufactureror dealer. At step 3906, the request for OEM API 128 is submitted to theappropriate dealer or vehicle manufacturer. At step 3908, the request islogged by dealer device 116. In step 3910, access is either granted ordenied. If access is granted, then in step 3912, dealer device 116provides technician device 124 with the application file for OEM API128. If denied, the process terminates. At step 3914 OEM API is updated.In step 3916, the updates are transmitted to technician device 124. Atstep 3918, technician device 124 downloads OEM API 128 and any updates.In a preferred embodiment, OEM API 128 is accompanied with an OEMapplication program and both are downloaded and installed on thetechnician device.

At step 3920, technician device 124 opens cloud-based web application.At step 3922, logon credentials are entered. In step 3924, the loginrequest is transmitted to system server 102. At step 3926, system server102 verifies the credentials entered. If the credentials are incorrect,then in step 3928, the request is denied by system server 102. If therequest is denied, then in step 3930, a denial message is transmitted totechnician device 124. If the credentials entered are correct, then instep 3932, the logon request is approved. In step 3934, a cloud-basedweb application program is generated. At step 3935, the web applicationprogram is transmitted to technician device 124. At step 3936, the webapplication program is displayed. In step 3937, the J2534 Applicationtab is selected. An example of the J2534 Application tab of the webapplication screen is shown in FIG. 41B. In step 3938, a version ofJ2534 application 126 is selected. In step 3940, a request to downloadthe selected version of J2534 application 126 is submitted. At step3942, the download request is transmitted to system server 102. In step3944, system server 102 logs the request. At step 3946, the selectedversion of J2534 application 126 program file is transmitted totechnician device 124. In step 3948, technician device downloads J2534application 126. The J2534 DLL file may be required for communicationbetween the manufacturer OEM application, client device, and localdevice. If so, the J2534 DLL is included in the J2534 applicationdownload. At step 3950, J2534 application 126 is installed on techniciandevice 124. In a preferred embodiment, installation of the applicationincludes installing the J2534 DLL file in the windows registry key[HKEY_LOCAL_MACHINE\SOFTWARE\PassThrusSupport .04.04].

Referring to FIG. 40A, a preferred embodiment of a system for remoteJ2534 reprograming of vehicle device 114 is described.

At step 4002, the cloud-based web application is opened on techniciandevice 124. At step 4004, logon credentials are entered. In step 4006,the login request is transmitted to system server 102. At step 4008,system server 102 verifies the credentials entered. If the credentialsare incorrect, then in step 4010, the request is denied by system server102. If the request is denied, then in step 4012, a denial message istransmitted to technician device 124. If the credentials entered arecorrect, then in step 4014, the cloud-based web application isgenerated. At step 4016, the web application program is transmitted totechnician device 124.

In step 4018, technician device 124 displays web application. In step4020, a client is selected and client profile details, such as email,and details of local device 112 and vehicle device 114 are shown. Instep 4022, a specific vehicle from a list of multiple vehicles isselected. In an alternate embodiment, an ECU profile configuration maybe selected from a list of optional configurations and downloaded to thetechnician device as follows. In step 4024, an ECU profile configurationfor a vehicle is selected from a list of potential ECU profiles. Anexample of a technician view of available ECU profile configurations isshown in FIG. 41C. At step 4026, the selected ECU profile configurationis requested.

At step 4028, the ECU profile configuration request is transmitted tosystem server 102. In step 4030, system server 102 will log the request.In step 4032, system server 102 will forward the request to calibrationwriter server 118. At step 4034, the request is logged. In step 4036,calibration writer server 118 will determine parameters for therequested profile based on selected client, selected vehicle, andselected ECU profile. For instance, when the ECU has a customconfiguration it may require different parameters for an ECU re-flashthen when the ECU has a standard OEM profile. At step 4038, the selectedprofile is transmitted to the system server. In step 4040, system server102 logs the profile. In step 4042, the profile is forwarded totechnician device 124. At step 4044, technician device 124 stores theprofile.

At step 4046, the current version of J2534 application 126 is opened ontechnician device 124. In step 4048, logon credentials are entered. Atstep 4050, the logon request is transmitted to system server 102. Atstep 4052, system server 102 verifies the credentials entered. If thecredentials are incorrect, then in step 4054, the request is denied bysystem server 102. If the request is denied, then in step 4056, a denialmessage is transmitted to technician device 124. If the credentialsentered are correct, then in step 4058, an approval message isgenerated. At step 4060, the approval is transmitted to techniciandevice 124. In step 4061, J2534 application 126 will display customerselection screen where a customer’s email address is entered. An exampleof the customer selection screen is shown in FIG. 43A.

In step 4062, the customer email address is entered. At step 4064, thecustomer email address is transmitted to system server 102. In step4066, system server will verify whether or not the customer emailaddress is correct. If customer email is incorrect or not permitted forservice, then in step 4068, system server 102 will generate a denial. Atstep 4070, the denial will be sent to technician device 124. If thecustomer email is correct, then at step 4072 the request is approved. Ifthe request is approved, then in step 4074, the approval is transmittedto technician device 124. In step 4075, J2534 application 126 willdisplay J2534 reprogramming screen and instructions as shown in FIG.43B.

In step 4076, customer chat option in J2534 application 126 may beselected on technician device 124 for communication prior to areprogramming request. While it is preferential that a technicianutilizes the chat function prior to initiating a reprogramming request,it is not required. If customer chat option is selected, then in step4078, the web application program opens and a request for access isgenerated. At step 4080, a request for access to the web application istransmitted to system server 102. At step 4082, the request is processedby system server 102. At step 4084, the web application is transmittedto technician device 124. In step 4086, web application is displayed.The web application will have a communication bar for communication withclients, as shown in FIG. 41A. In step 4088, text is input into theclient chat communication bar and is received by the technician device.At step 4090, the “send” option next to the text input is selected. Atstep 4092, the text is transmitted to system server. In step 4094,system server logs the text. At step 4096, system server 102 forwardsthe text to client device 110 that is associated with the clientselected. At step 4098, client device 110 receives an applicationnotification. In step 4099, application 111 is opened on client device110. In step 4100, chat notification is displayed within application111. An example of a chat notification is shown in FIG. 44A. In step4101, the chat option is selected in application 111 and the texted fromtechnician device 124 is displayed. At step 4104, response text isreceived. If response text is entered, then in step 4106, the responsetext is transmitted to system server 102. In step 4108, system server102 logs the response text. At step 4110, system server 102 forwards theresponse text to technician device 124. In step 4112, response text isdisplayed and the communication process may repeat as necessary.

In step 4114, the web application is minimized and J2534 application 126is reopened on technician device 124. In step 4116, the graphicalrepresentation of a button for the option to “proceed” with J2534reprogramming is selected. In step 4118, J2534 application 126 willgenerate a reprogramming request. At step 4120, the reprogrammingrequest is transmitted to system server 102. In step 4122, the requestis logged and analyzed. In step 4124, a denial message is generated ifthe request does not meet system requirements, or if there is an error.At step 4126, a denial is transmitted to technician device 124. At step4128, system server 102 generates a request notification message for theclient, if the request meets requirements. At step 4130, a reprogrammingrequest notification is forwarded to client device 110. In step 4132,client device 110 receives the reprogramming request notification. Instep 4134, the reprogramming request is displayed. An example of thereprogramming request screen is shown in FIG. 44B.

In step 4136, the graphical depiction of a button for “Accept” isselected in application 111. In step 4138, client device 110 generatesan accept message. At step 4140, the message is transmitted to systemserver 102. At step 4142, system server 102 logs the message. In step4144, system server 102 forwards the message to technician device 124.In step 4146, J2534 application 126 logs the acceptance. At step 4148,J2534 application 126 displays J2534 reprogramming screen withdirections on technician device 124. An example of the reprogrammingscreen is shown in FIG. 43C.

In step 4150, the OEM application is opened on technician device 124.The OEM application uses OEM API 128 to communicate with the localdevice through the system server and client device. In a preferredembodiment, the J2534 DLL file downloaded on the technician device withJ2534 application 126 is automatically recognized by the OEMapplication. In step 4152, local device 112 and ECU profile are selectedin the OEM application. In a preferred embodiment, the OEM applicationis directed to the system server for the data file of the ECU profileselected. At step 4154, the reprograming is initiated. In a preferredembodiment, this step consists of the OEM API using the J2534 DLL toserialize a reprogramming request for transmission to the system server.

In step 4156, a reprogramming command is sent to system server 102. In apreferred embodiment, the reprogramming command includes the ECU profilechoice and the OEM J2534 communication functions. At step 4158, thecommand is logged. At step 4159, system server 102 assembles areprogramming request file. In a preferred embodiment, the reprogrammingfile includes the chosen ECU profile data file and the OEM APIfunctions. In another embodiment this step is performed on thetechnician device. In step 4160, system server 102 transmits thereprogramming request file to client device 110. At step 4162, clientdevice 110 downloads the reprogramming request file. In step 4164,application 111 enables J2534 mode. J2534 mode disables use of otherfeatures of the phone while reprogramming is performed. An example ofthe screen displayed in application 111 is shown in FIG. 44C. In step4176, the graphical depiction of “Stop” may be selected to end thereprogramming after it has been initiated. In step 4178, application 111will a display warning screen if “Stop” is selected after J2534 mode isenabled. An example of the warning screen is shown in FIG. 44D. In step4180, the graphical depiction of a button to “proceed” may be selectedto disable J2534 mode and stop reprogramming. If the reprogramming isstopped, then in step 4182, the cancellation of reprogramming istransmitted to the system server 102. In step 4184, system server 102will log the cancellation. At step 4186, system server 102 will forwardthe cancellation notification to technician device 124.

In step 4166, client device 110 will establish a connection with localdevice 112 via a local area network, Wi-Fi or Bluetooth, or wide areanetwork, GSM, once J2534 Mode is enabled. Both the local area networkand the wide area network can be connected simultaneously, as previouslydescribed. In step 4168, client device will transfer the reprogrammingfile to local device 112 once communication is established. In step4170, local device 112 will download the reprogramming request file. Instep 4172, local device will deserialize the reprogramming request anduse the OEM J2534 communications functions to initiate the reprogrammingprocess. In step 4174, local device 112 will initiate a communicationconnection with vehicle device 114 through the OBD II port utilizing theJ2534 compliant OEM communications functions, such as those shown inTable 2.

TABLE 2 Function Description PassThruOpen Establish a connection with adevice PassThruClose Terminate a connection with a devicePassThruConnect Establish a connection with a protocol channelPassThruDisconnect Terminate a connection with a protocol channelPassThruReadMsgs Read messages form a protocol channel PassThruWriteMsgsWrite messages to a protocol channel PassThruStartPeriodicMsg Startsending messages at a specified time interval on a protocol channelPassThruStopPeriodicMsg Stop a periodic message PassThruStartMsgFilterStart filtering incoming messages PassThruStopMsgFilter Stop filteringincoming messages PassThuSetProgramming Voltage Set programming voltageon a specific pin PassThruReadVersion Read version information for theDLL and API PassThruGetLastError Get text description of the last errorPassThruloctl General I/O control functions for reading and writingprotocol configuration parameters

The communication protocols which can be used at this step and arecurrently supported by the J2534 standard are: ISO9141, ISO14230(KWP2000), J1850, CAN (ISO11898), ISO15765, SAE J2610, and J1939.

Once the communication connection is established, then in step 4188,local device will transmit the ECU profile data selected forreprogramming. In step 4190, vehicle device 114 will acknowledge theconnection and transmittal. At step 4192, vehicle device 114 willinitialize reprogramming according to the new ECU profile parameters. Atstep 4194, vehicle device will complete all reprogramming.

In step 4196, the vehicle device will transmit a completion message. Instep 4198, local device 112 will log completion and serialize themessage. At step 4200, local device 112 will transmit a completionmessage to client device 110. In step 4202, client device logs thecompletion. Then in step 4204, the completion message is forwarded tosystem server 102. At step 4206, system server logs the completion. Atstep 4208, system server will update the database. At step 4210, acompletion message is forwarded to technician device 124. In step 4212,technician device 124 receives a notification of reprogrammingcompletion and the OEM API will deserialize the message for the OEMApplication using the J2534 DLL file. At step 4214, the reprogrammingcompletion screen is displayed. An example of the reprogrammingcompletion screen is shown in FIG. 43D.

At step 4216, the completion of J2534 reprogramming of vehicle device114 is confirmed. In step 4218, technician device 124 transmits aconfirmation message to system server 102. In step 4220, system server102 will log confirmation. In step 4222, system server 102 will generatea complete notification. In step 4224, the complete notification istransmitted to client device 110. In step 4226, client device 110receives the completion notification. At step 4228, application 111 willdisable J2534 mode. At step 4230, application 111 will display a messagewhich indicates that J2534 mode is now disabled and reprogramming iscomplete. An example of this screen is shown in FIG. 44E.

Referring then to FIG. 40B, method 4250 of communications between an OEMapplication and vehicle device is described.

In a preferred embodiment, method 4250 requires a PC, or other smartdevice, such as technician device 4271, with OEM application 4251, J2534compliant OEM API 4252, and J2534 DLL 4253. Method 4250 also uses asystem server 4255, client device 4260, local device 4263, and a vehicleECU, such as vehicle device 4265, networked together as previouslydescribed. Method 4250 also includes third-party server 4272 andreporting monitor server 4259 connected to the system server through awide area network, such as the internet (not shown). In one embodiment,third-party server 4272 is controlled by a vehicle manufacturer and alsocommunicates with the technician device through the wide-area network.Third-party server 4272 is accessible from an OEM application providedby the vehicle manufacturer, such as OEM application 4251. The OEMapplication may receive updates and ECU data files from the third-partyserver in response to requests from the OEM application.

In method 4250, the system server, client device, and local device caneach operate in a “pass-through” mode. In pass-through mode, the devicescollectively act as an interface between an OEM application, located onthe technician device, and the vehicle device. The OEM applicationcontrols the J2534 reprogramming of a vehicle device, while the systemserver, client device, and local device relay the OEM commands from theOEM application to the vehicle device. In this embodiment, the systemserver neither interprets an OEM reprogramming command, nor compiles areprogramming request file.

Module 4251 comprises the OEM application. The OEM application typicallyis provided by a vehicle manufacturer and enables ECU reprogrammingthrough a direct connection to the OBD II port. The OEM applicationincludes J2534 compliant OEM API 4252, the software and calibration datafor a vehicle device, the security mechanism that controls access toprogram a vehicle device, and the steps and sequence required to programa vehicle device as will be further described. OEM application 4251 mayretrieve new software and calibration data for a vehicle device orupdated security mechanisms from the vehicle manufacturer throughthird-party server 4272.

In a preferred embodiment, the OEM application utilizes the J2534communications functions shown in Table 2. The programming sequencesused to reprogram the ECU correspond with the J2534 communicationsfunctions required by the J2534 Protocol. The OEM application alsoprovides a user interface to select a vehicle device for reprogramming,as well as the calibration data, or ECU profile. In a preferredembodiment, once a vehicle device and ECU profile are selected, the OEMapplication uses the OEM API to call the J2534 DLL file for the localdevice connected to the vehicle device, as will be further described.

J2534 DLL 4253 comprises modules 4254, and 4270. In a preferredembodiment the DLL is located in the following registry key in thetechnician device registry:[HKEY_LOCAL_MACHINE\SOFTWARE\PassThruSupport.04.04]. Module 4254, instep 1, makes an OEM API call to the J2534 DLL file in order toserialize the reprogramming command request. The serializedreprogramming request contains the J2534 OEM communications functions,and data, or programming sequence, required to install the ECU profileselected from the manufacturer. In a preferred embodiment, the processof serialization consists of converting the reprogramming request fromhalf-duplex to binary array for full-duplex transmission throughWebSocket. In step 2, module 4254 sends the serialized data to modules5256 and 5257 resident on system server 4255 by virtue of the wide areanetwork.

System server 4255 comprises modules 4256, 4257, 4258, 4268, and 4269.In module 4256, the system server operates in pass-through mode. Inpass-through mode, the system server simply relays data from one deviceto another. In module 4256, the system server then relays the serializedcommand to client device 4260.

In module 4257, system server 4255 deserializes the data so that it canbe interpreted and packaged for further transmission. Module 4258, instep 1 logs the API request and in step 2 reports the API request toreporting monitor server 4259. In one embodiment reporting monitorserver 4259 is operated by a third-party, such as a fleet manager. Thisfunction monitors and reports ECU changes in order to verify that theemissions controls operate within applicable emissions regulations. Thisfunction is important because it enables automatic compliance withreporting regulations.

Client device 4260 contains mobile application 4262 for communicatingwith the local device and system server, such as application 111, aspreviously described. Client device 4260 also comprises modules 4261 and4266. Module 4261 receives the serialized reprogramming command from thesystem server and retransmits it to local device 4263. At this step,application 4262 may display a notification to the user that emissionsreprogramming is underway or has been requested. At this step, theapplication also establishes a wireless connection by Wi-Fi or Bluetooth(or both) with the local device in order to transfer the reprogrammingcommand request. The reprogramming request is then uploaded to the localdevice.

Local device 4263 comprises modules 4264, 4266 and buffer 4275. Localdevice 4263 is operatively connected to a vehicle device through an OBDII port, as previously described. Module 4264, in step 1, deserializesthe reprogramming request and submits it to the vehicle device. In apreferred embodiment, deserialization consists of converting thereprogramming command from a full-duplex binary array to half-duplex fortransmission to the vehicle device. The half-duplex communication systemused to communicate with a vehicle device varies, however, thecommunication protocols currently supported by the J2534 protocol areISO9141, ISO14230 (KWP2000), J1850, CAN (ISO11898), ISO15765, SAE J2610,and J1939. The deserialized data consists of the J2534 OEM communicationfunction request and data sent from the technician device. The functionsare used to communicate with a vehicle device to initiate and executethe ECU reprogramming. In step 2, module 4264 submits the functionrequest and data for transfer to buffer 4275.

The vehicle device may receive communication in either a single frame orsegmented messages in multiple frames. For instance, the J2534 OEMcommunications functions are single frame requests. Whereas, datamessages, such as those containing reprogramming parameters, must besegmented to comply with the size restrictions of the communicationprotocol used by a vehicle device, such as those listed in Table 3.

Protocol Minimum bytes Maximum bytes CAN (ISO11898) 4 12 ISO15765 4 4099ISO15765 (Extended Address) 5 4100 J1850PWM 3 10 J1850VPW 1 4128 ISO91411 4128 ISO14230 1 259 ISO14230 (Manual Checksum) 1 260 SCI 1 4128

The J2534 OEM communication functions are sent in single frame transfersto the vehicle device and cannot be segmented. However, these functionsmust be received in a certain order. Specifically, communication withthe vehicle device must always begin with the function PassThruOpen,with one exception, the function PassThruGetLastError. If any otherfunction or message is received prior to PassThruOpen, an error results.A successful result of PassThruOpen returns a device ID which is thenused as a handle for subsequent functions and messages. Generally,PassThruConnect must be the first function to follow PassThruOpen, and asuccessful result will return a protocol ID. Together the device ID andprotocol ID form a pChannelID, which the local device thereafter will beable to use to communicate with the vehicle device.

Similarly, segmented messages must be received in the correct order, andmust follow a read/write function, such as PassThruReadMsg orPassThruWriteMsg. The first message in the series will have a “start”indicator. When a start indicator is received it is matched to a flowcontrol filter, or pPatternMsg, with the same CAN ID. The flow controlstatus is then set to ContinueToSend, and the vehicle device will waitfor the consecutive frames. The final segmented message will have an“end” indicator. All of the segmented messages must be received beforethe vehicle device can read the data. If the separation time parametersare too long, or any messages are delayed the process will time out andproduce an error. Transmission over wide-area networks is prone todelays and interference. Therefore, it is important to buffer and queuemessages and functions in order to reduce the likelihood that an errorwill occur transmitting sequential and segmented messages to the vehicledevice over a wide area network.

Buffer 4275 is a data buffer for the J2534 OEM communication functionsand data messages submitted for transfer to the vehicle device. Inbuffer 4275, functions and messages are queued and ordered to reduce thepossibility of receiving an error from the vehicle device. The buffer iscapable of receiving at minimum 8 simultaneous messages and 4128 bytesper message. This is important because J2534 OEM communication functionsand data messages must be sent to and received by the vehicle device inthe correct order and within a specified time period otherwise errorsmay occur. An example is ERR_TIMEOUT where the timeout period is 35seconds, or ERR_INVALID_CHANNEL_ID where the functions are received outof order.

Vehicle device 4265 comprises an ECU and various controllers andmemories, such as vehicle device 114, as previously described. Vehicledevice 4265 interprets and executes the reprogramming commands sent viathe J2534 OEM communication functions and installs the parameters of thenew ECU profile. The vehicle device either returns an “error” or aconfirmation code to the local device using the J2534 OEM communicationsfunctions. An error is returned where the J2534 OEM communicationsfunctions are wrong or out of sequence, or if the reprogramming cannototherwise be completed. A confirmation is returned when thereprogramming functions are performed successfully. The error orconfirmation message is reported to module 4266 of the local devicethrough the OBD II port. The vehicle device may send responses in singleframe messages or segmented messages. However, unlike the communicationfunctions and data sent to the vehicle device, the responses receivedfrom the vehicle device do not need to be received in sequential order.

In module 4266, local device 4263, in step 1, serializes the responsereturned from the vehicle device. In a preferred embodiment, theserialization of the response consists of the local device convertingfrom half-duplex to full-duplex, as previously described. In step 2,module 4266 then transmits the serialized response to module 4267 of theclient device.

In module 4267, client device 4260 uploads the serialized response tomodules 4268 and 4269 of the system server. At this step application4262 may send or display a message to the user as to the status of theECU reprogramming.

Module 4268 relays the serialized response from the client device tomodule 4270 of the technician device in pass through mode using afull-duplex communication system, such as WebSocket, as previouslydescribed.

Module 4269 deserializes the response and sends it to module 4258.Module 4258, then in step 3, logs the API response. In step 4, module4258 reports the API response to reporting monitor server 4259.

In module 4270, OEM API 4252 uses J2534 DLL 4253 in step 1 todeserialize the vehicle response and in step 2, in one embodiment,provides it to buffer 4274. Buffer 4274 acts as a queue for incomingJ2534 responses to the original J2534 OEM requests. The buffer iscapable of receiving a least 8 messages of 4128 bytes in length. Thebuffer is also capable of arranging the messages into the correct order.Once the messages are complete, and in the correct order, the buffer isdumped to OEM application 4251.

In another embodiment, the responses are not required to be received inorder or within a predetermined period. In this case, the buffer isbypassed or is omitted from technician device 4271.

The OEM application then typically displays the status of thereprogramming command to the technician user.

Referring to FIGS. 41A through 41C, graphic displays of a cloud-basedweb application generated for technician device 124 are shown. In FIG.41A, a screenshot of the cloud-based web application is shown displayingtechnician web app view 4301. Technician web app view 4301 consists ofcustomer chat panel 4304, text input bar 4306, and ECU configurationoption column 4308. Customer chat panel 4304 displays any text exchangedbetween a technician device and a client device, as well as reprogramrequest message 4310, J2534 mode enabled message 4312, and completionmessage 4314. ECU configuration option column 4308 contains a list ofpreconfigured ECU profiles.

In FIG. 41B, a screenshot of the cloud-based web application is showndisplaying technician web app view 4302. Technician web app view 4302shows the J2543 tab of the cloud-based application, which consists ofJ2534 application version numbers 4316, application release notes 4318,and download option 4320. J2534 application 126 is downloaded totechnician device 124 using download option 4320. Release notes 4318 areinput from administrator device 22032 when J2534 application 126 isuploaded to system server 102.

In FIG. 41C, a screenshot of the cloud-based web application is showndisplaying technician web app view 4303. Technician web app view 4303shows the ECU profile tab view of the cloud-based web application. TheECU profile tab contains calibration ID folder column 4322, vehiclecolumn 4324, ECU profiles column 4326, filter options 4328, and helpmenu pull out 4330. Calibration ID folder column 4322 consists of a listof calibration ID folders, each folder contains a specific number ofpre-configured ECU profiles, the total number of ECU profiles is listedin ECU profiles column 4326. The ECU profiles are preconfigured forspecific vehicles listed in vehicle column 4324. Calibration ID foldercolumn 4322 may be limited by a selection of specific vehicle filterslisted in filter options 4328. Help menu pull out 4330 shows shortcutsto a list of supported vehicles, and instructions as to how to usecustom ECU profiles, and how to perform J2534 reprogramming. Specificvehicle calibrations may be selected from the list of availableconfiguration ID folders and profiles.

Referring to FIG. 42 , a graphic display of the administrator webapplication is shown displaying admin view 4332. Admin view 4332 is aview of J2534 configuration page with upload window 4334. Upload window4334 contains file select option 4336, private comment box 4338, releasenotes box 4340, and add button 4342. New J2534 application versions areselected from local memory of administrator device 22032 and uploaded tosystem server 102 using upload window 4334.

Referring to FIGS. 43A through 43D, graphic displays of J2534application 126 on technician device 124 are shown. In FIG. 43A, ascreenshot of J2534 application 126 is shown displaying J2534application screen 4352. J2534 application screen 4352 consists ofcustomer input box 4360, and next option 4362. The email submittedthrough the application must be a valid customer email registered onsystem server 102.

In FIG. 43B, a screenshot of J2534 application 126 is shown displayingJ2534 application screen 4354. J2534 application screen 4354 consists ofreprogramming initiation instructions 4364, customer chat option 4366,and proceed option 4368. Selection of customer chat option 4366 opens upa web browser with technician view cloud-based web application as shownin FIG. 41A.

In FIG. 43C, a screenshot of application 126 is shown displaying J2534application screen 4356. J2534 application screen 4356 consists ofreprogramming instructions 4370, customer chat option 4366, and newreprogramming option 4372. Selecting new reprogramming option 4372 willcomplete the current reprogramming process.

In FIG. 43D, a screenshot of technician device 124 with J2534application 126 open is shown displaying J2534 application screen 4358.J2534 application screen 4358 consists of J2534 application screen 4356,as shown in FIG. 43C, with confirmation window 4374. Confirmation window4374 consists of confirm instructions 4376, and confirm option 4378.

Referring then to FIGS. 44A through 44E, a graphic display of clientdevice 110 is shown. In FIG. 44A, a mobile phone screenshot ofapplication 111 is shown displaying mobile application screen 4402.Mobile application screen 4402 consists of tile panel 4412, andreprogramming request notification 4414. Tile panel 4412 consists ofvarious tiles that give the status of a vehicle’s systems, such as theengine temperature, current speed, and rpm. Reprogramming requestnotification 4414 is selected to view the reprogramming request in themobile chat panel.

In FIG. 44B, a mobile phone screenshot of application 111 is showndisplaying mobile application screen 4404. Mobile application screen4404 consists of mobile chat panel 4416, text input box 4422, and sendoption 4424. Mobile chat panel 4416 displays text exchanged betweentechnician device 124 and client device 110, and reprogram request 4418.Reprogram request 4418 contains accept option 4420. Reprogramming willnot initiate unless accept option 4420 is selected.

In FIG. 44C, a mobile phone screenshot of application 111 is showndisplaying mobile application screen 4406. Mobile application screen4406 is a view of mobile chat panel 4416 which contains J2534 modeenabled message 4426, and stop option 4428.

In FIG. 44D a mobile phone screenshot of application 111 is showndisplaying mobile application screen 4408. Mobile application screen4408 consists of warning window 4430. Warning window 4430 consists ofwarning message 4432, cancel option 4433, and proceed option 4436.

In FIG. 44E, a mobile phone screenshot of application 111 is showndisplaying mobile application screen 4410. Mobile application screenconsists of chat panel 4416 with complete message 4434 indicating thereprogramming was conducted successfully.

Referring then to FIG. 45 , the system for determining the carbonemissions of a vehicle is described. In many states in the UnitedStates, carbon emissions and offsets are subsidized upon certificationby a third-party certification agency.

At step 4502, client device 110 receives a signal choosing the carbonemissions offset program. In step 4504, the opt-in is transmitted tosystem server 102. In step 4506, system server 102 records the signal.At step 4508, system server 102 generates an offset command message forlocal device 112 to initiate an onboard carbon offset module. In step4510, offset command message is transmitted to client device 110. Atstep 4512, client device 110 logs the command message. In step 4514,client device 110 forwards the command message to local device 112. Instep 4516, local device 112 logs the command message.

At step 4518, local device 112 initiates the onboard carbon offsetmodule. The onboard carbon offset module determines and stores thevolume of fuel consumed by a vehicle. At step 4520, local device 112generates and repeats a fuel consumption request once every preset timeperiod. In a preferred embodiment the preset time period is about onesecond. Other preset time periods can be used. A lower preset time limitresults in greater accuracy of the amount of fuel used, but requireshigher processor usage. A higher preset time limit results in lessaccuracy of the amount of fuel used, but also lower processor usage.

In step 4522, the fuel consumption request is transmitted to vehicledevice 114. The fuel consumption request is sent using either a singleParameter ID (PID) or any combination of PIDs. For instance, in oneembodiment the fuel consumption request uses one or more J1979 StandardOBD II PIDs, such as RPM 0xOC, Speed 0×0D, MAF rate 0×10, Throttle Pos0×11, 02 Sensor 0×34, Fuel injection timing 0×5D, and Engine Fuel Rate0×5E. In other embodiments, the fuel consumption request usesnon-standard manufacturer specific PIDs.

In step 4524, vehicle device 114 logs the fuel consumption request. Atstep 4526, vehicle device 114 retrieves the data requested. At step4528, the data is sent to the local device. At step 4530, the data isstored in memory. At step 4531, the local device calculates fuelconsumption.

In one embodiment, fuel consumption is determined by using the Mass AirFlow Rate (MAF), and the Air/Fuel Ratio (AFR) at a specific timeinterval. MAF and AFR values may be requested directly from the vehicledevice using J1979 Standard OBD-II PIDs, such as 0×10 and 0×34,respectively.

Fuel consumption, M_(x), is calculated by the formula:

$M_{x} = \frac{MAF}{AFR} \times t$

where:

$MAF = \frac{Grams_{Air}}{second}$

$AFR = \frac{Grams_{Air}}{Grams_{Fuel}}$

t = time interval in seconds.

AFR can be determined by the formula:

AFR = λ × S_(r)

where:

-   S_(r) is the stoichiometric ratio of fuel, typically 14.7 grams air    per one (1) gram of fuel, and-   λ is the Equivalence Ratio, which is the ratio of actual AFR to    ideal stoichiometric ratio determined by the formula:-   $\lambda = \frac{AFR}{14.7}$

In another embodiment, fuel consumption, M_(x), is determined by usingnon-standard PIDs for fuel consumption, where a manufacturer hasprogramed an ECU to monitor fuel consumption.

In yet another embodiment, fuel consumption, M_(x), may be determined byusing injector timing, injector pulse width and injection amount asfollows.

M_(x) = m × S

where:

-   S is the number of piston strokes during time interval t; and,-   m is the mass of fuel injected per stroke in kg, found using the    following formula;-   $m = \frac{A}{a} \times P \times pw$-   where:    -   A is the cross-sectional area of an engine fuel cylinder in m²;    -   a is the speed of sound in the fluid in    -   $\frac{\text{m}}{\text{s}};$    -   P is the pressure in the cylinder in Pascals, or kg/m*s²; and    -   pw is the pulse width, or the change in time from the start of        injection (SOI) to the end of injection (EOI) in seconds.

M_(x), is converted to gallons according to the following formulas:

$Fuel_{grams} = \frac{Fuel_{kg}}{1000}$

$Fuel_{Lbs} = \frac{Fuel_{grams}}{454}$

$Fuel_{Gallons} = \frac{Fuel_{Lbs}}{6.701}$

At step 4532, local device 112 stores the value of fuel consumed ascalculated. In step 4534, local device 112 adds the amount of fuelconsumed to a cumulative total of fuel consumed stored in memory. Atstep 4535, local device 112 adds the value of time elapsed during whichfuel has been consumed to a cumulative total.

At step 4536, system server 102 generates an emissions request. In step4538, the emissions request is transmitted to client device 110. Inanother embodiment, an emission request may be initiated by the user. Atstep 4539, client device 110 generates an emissions request. In step4540, client device 110 logs the emissions request. At step 4542, therequest is forwarded to local device 112.

At step 4543, local device 112 logs the request. In step 4544, the localdevice determines the cumulative elapsed time. In step 4545, localdevice retrieves the cumulative total of fuel consumed. At step 4546,local device 112 requests fuel type used. In a preferred embodiment fueltype can be determined using J1979 Standard OBD II PID, Fuel Type 0×51,or non-standard manufacturer specific PIDs.

In step 4547, the fuel type request is transmitted to vehicle device114. In step 4548, vehicle device 114 determines fuel type used. At step4549, fuel type is transmitted to local device 112. In step 4550, fueltype is logged in the local device’s memory. At step 4551, local device112 transmits fuel type, cumulative total of fuel consumed, and thecumulative elapsed time to client device 110. In step 4552, clientdevice 110 logs the data. In step 4552, client device 110 transmits fueltype, cumulative total of fuel consumed, and the cumulative elapsed timeto system server 102.

At step 4554, system server 102 logs the cumulative total of fuelconsumed, the cumulative elapsed time and the fuel type. In an alternateembodiment, fuel type can be determined independently by system server102. In step 4556, optionally, system server 102 determines the type offuel used by the vehicle associated with local device 112 by using theVIN and consulting a loop-up table.

At step 4558, system server 102 determines the fuel type’s emissionsfactor, E_(f). In a preferred embodiment, emissions factors are storedlocally at the server in a table.

In another embodiment, the emissions factor, E_(f), is calculated by theserver. Emissions factors represent kg CO₂ emitted per gallon of fuelcombusted. Emissions factors are calculated by the following equation:

$E_{f}\frac{kg\mspace{6mu} CO_{2}}{Gallon} = Fuel_{Heat\mspace{6mu} Content} \times Fuel_{CO_{2} Factor}$

where:

$Heat\mspace{6mu} Content = \frac{mmBtu}{Gallon}$

and

$CO_{2}\mspace{6mu} Factor = \frac{kg\mspace{6mu} CO_{2}}{mmBtu}$

At step 4560, system server 102 calculates carbon emissions, C_(e), fora vehicle. The C_(e) is calculated by the following equation:

$C_{e} = Fuel_{Gallons} \times E_{f}\frac{kg\mspace{6mu} CO_{2}}{Gallon}$

where:

Fuel_(Gallons) = fuel consumption,

assuming all carbon is converted to CO₂ during combustion.

In an alternate embodiment, local device 112 calculates C_(e) at step4561. At step 4562 the local device sends it to client device 110 fordisplay and transmission to system server 102.

At step 4563, system server 102 stores the value of C_(e). At step 4564,system server 102 generates a carbon emissions report. The emissionsreport comprises the value of C_(e), the identity of the vehicle,preferably by VIN, and the identity of the owner.

In step 4566, the carbon emissions report is transmitted to athird-party for certification. At step 4567, the carbon emissions reportis transmitted to client device 110. In step 4568, the carbon emissionsreport is displayed.

In step 4569, third-party server 22020 logs the emissions report. Atstep 4570, the carbon offset is determined and certified. In a preferredembodiment a unique certification number is generated and provided asevidence of the certification. In step 4572, the certification istransmitted to system server 102. In step 4574, system server 102 storesthe certification. At step 4576, system server generates a carbon offsetmessage. In step 4578, the carbon offset message is transmitted toclient device 110. At step 4580, client device 110 displays the carbonoffset message.

Referring then to FIG. 46 , system 4600 is provided. System 4600includes display device 4602, local device 4604, and vehicle device4606.

In a preferred embodiment, display device 4602 is connected to localdevice 4604 using a USB connection and/or a local wireless network, suchas Wi-Fi or Bluetooth. Local device 4604 is hardwired to an automotivecontroller, such as vehicle device 4606. The local device communicatesto the vehicle device through a dedicated local area network. Vehicledevice 4606 is connected to sensors 4608 and actuators 4610, resident onthe vehicle, as previously described.

Referring then to FIG. 47 , an architecture drawing of a preferredembodiment of display device 4602 is described.

Display device 4602, contains processor 4612, memory 4614, andcommunication interface 4618. Memory 4614 may be any combination of RAM,ROM, or secondary memory, such as a removable memory card, as previouslydescribed. Memory 4614 contains application 4616 which provides the userinterface and instructions for communicating with the local device. In apreferred embodiment, communication interface 4618, includes a USBinterface and local area network connectivity, such as Wi-Fi orBluetooth. Optionally, communication interface may also include widearea network connectivity, such as cellular. The communication interfacecan also include a data buffer for temporary storage and metering oflive feed data from the local device.

Display device 4602 is operatively connected to keypad 4622 and monitor4620. In a preferred embodiment, keypad 4622 is a touchscreen.

Referring then to FIG. 48 , operation of a preferred embodiment ofsystem 4600 will be described as method 4800. In use, the display deviceallows the viewing of vehicle information, such as speed, RPM, andcoolant temperature, without the use of a client device, such as acellphone or other smart device.

At step 4802, the display device is setup. Setup of display device 4602includes providing power to the display, powering up the device,entering demographic information, such as location and time, andsearching for a local device to connect to via Wi-Fi or Bluetooth, orplugging in the USB cable, as previously described. In step 4803, aconnection is established between local device and display device.

In step 4804, display settings are selected. In a preferred embodiment,in this step a user can select which gauges to view and monitor, and atwhat refresh rate. A user may select one or more gauges to view on thedisplay in a tile format, such as the carbon emissions, speed, enginecoolant temperature or RPMs, as previously described. The display willupdate the gauges selected at a refresh rate selected by the user. Forinstance, a user may wish to see his RPM at a refresh rate of ¼^(th) ofa second. Additional functions for commercial motor vehicles may also beselected, as will be further described below. At step 4806, displaydevice 4602 stores gauge and refresh rate selections.

In step 4808, the display device requests a live data feed. In apreferred embodiment, the display device will only request a live datafeed of the gauges selected. In an alternate embodiment, the display mayrequest a data feed of all available gauges. At step 4810, the displaydevice transmits the data request to local device 4604.

At step 4812, the local device logs the request. At step 4814, localdevice transmits the PIDs for the specified gauges, such as thosepreviously described and listed in Table 1. In step 4816, the vehicledevice determines the status of the gauges requested. At step 4818, thePID values are transmitted to the local device. At step 4820, the localdevice stores the status.

In step 4822, local device 4604 uploads the status of the gauges todisplay device 4602. In step 4824, the display device will store thestatus. In a preferred embodiment the display device will store thestatus in temporary memory, such as RAM, and eventually discard thevalues. In another embodiment, the display device may contain an ongoingFIFO record of the values in a local secondary memory, such as a memorycard or SSD.

At step 4826, the status of the selected gauges is displayed. At step4828, the display device loops the data request as frequently as theselected refresh rate requires.

Referring then to FIG. 49 , a diagram of an exemplary embodiment of adisplay device and a user interface of application 4616 is described.

Display device 4602 includes on/off button 4624, USB port 4630, andpower port 4628. Optionally, USB port 4630 and power port 4628 arecombined to accommodate USB for both connectivity and power. The displaydevice may optionally have connection button 4626. The connection buttonmay reset the device’s wireless connection with a local device orinitiate Wi-Fi protected setup (WPS) to establish a quick connectionwith a local device equipped with WPS technology.

Monitor 4620 is shown displaying screen 4621, which is an exemplary userinterface of application 4616. Screen 4621 contains settings option4629, which would display available options such as gauge selection tab4631, refresh rate tab 4632, and connections tab 4634. In a preferredembodiment, gauge selection tab 4631 will contain gauge list 4635displaying a multitude of options available for a user to select, suchas carbon emissions, speed, engine coolant temp, RPM, etc.

Referring then to FIG. 50 , system 5000 is provided for commercial motorvehicle fleet management. Commercial motor carriers are typicallyresponsible for compliance with federal and state regulations. Forinstance, FMCSA requires that each vehicle must be equipped with anelectronic logging device (“ELD”) which records vehicle data, such asengine power status, vehicle motion status, miles driven, and enginehours. The ELD must maintain a record of duty (“ROD”) including varioustypes of vehicle data and driver hours of service (“HOS”). Compliancerequires that the RODs and HOS stored on the ELD must be accessible bythird-party safety officials for safety audits. Motor carriers areultimately responsible for drivers that are not compliant. As anotherexample, CMVs must remain compliant with the Federal carbon emissionsregulations, so the functionality of a vehicles emission control systemsneeds to be monitored to maintain compliance. As yet another example ofFederal regulations, under the International Fuel Tax Agreement (IFTA),interstate CMVs must file a motor fuel tax report quarterly.

System 5000 provides additional functionality for a commercial motorvehicle to monitor and record data as needed to comply with variousregulations, such as those previously described. Motor carriers aresimilarly responsible for the efficiency of their fleet. If a vehicle isnot running efficiently, has a sensor fault, or other error, a fleetmanager needs to be aware that the vehicle may need to be decommissionedfor service. Thus, the ability of a motor carrier, or fleet manager, tomonitor an individual vehicle and driver record is crucial for overallfleet performance.

System 5000 includes technician device 5004, administrative server 5006,local device 5012, third-party device 5020, and fleet manager device5022 all connected through network 5002. Network 5002 is a wide-areanetwork such as the internet. Administrative server 5006 is operativelyconnected to database 5008. Local device 5012, as previously described,is operatively connected to vehicle device 5014 and connected to displaydevice 5010 wirelessly or via USB, as previously described. Vehicledevice 5014 is connected to sensors 5016 and actuators 5018 resident onthe vehicle, as previously described. In an alternate embodiment,display device 5010 may also be connected to network 5002 when equippedwith a GSM module on communication interface 4618.

Referring to FIGS. 51A through 51E, network flow diagrams of system 5000for fleet management will be described.

Referring then to FIG. 51A, method 5100 for enabling ELD mode on a localdevice using a display device, such as display device 5010, isdescribed. The method described in reference to FIG. 51A may be usedwhen any advanced commercial motor vehicle functions are selected foruse, such as ELD mode, carbon emissions monitoring, or fuel taxreporting. At step 5105, the display device receives an ELD modeselection. In a preferred embodiment, when this feature is selected aunique identifier for the local device is used to identify the vehicle.This unique identifier may be issued to the local device at the time ofmanufacture, such as a serial number. Alternatively, this uniqueidentifier may be issued when ELD mode is selected. In anotherembodiment, a commercial motor carrier, vehicle, or driver may have aunique identifier, issued by the administrative server, which is inputat step 5105 to automatically link the vehicle to a fleet.

At step 5106, the ELD mode selection is transmitted to local device5012. In step 5107, the local device logs the request. At step 5108, therequest is transmitted to administrative server 5006. In a preferredembodiment, the request includes the CMV function selected in step 5105and the unique identifier associated with the device.

At step 5109, the request is processed by the administrative server. Ina preferred embodiment, this process includes a review of accounthistory and payment through receipt of existing tokens, as previouslydescribed. Optionally, the process may verify the request accuracy andprocess the receipt of funds from a bank via wire transfer or a creditcard transaction. If existing tokens are utilized to activate therequested functionality, the token status is updated to “used”.

At step 5110, an approval is transmitted to local device 5012. At step5111, an ELD mode module on the local device is switched on. This modulewill monitor and log vehicle data and driver data. In step 5112, thelocal device will request a data sync for the required vehicle data. At5113, local device establishes a data sync with vehicle device 5014 viaa direct connection through an OBD II port.

At step 5114, the vehicle device continuously generates data, such aspower status, motion, miles driven, and engine hours, through use. Atstep 5115, vehicle device 5014 will transmit the vehicle data to thelocal device. At step 5116, local device 5012 records the data. In step5117, the local device will generate and continuously update a log ofvehicle and driver data (i.e. RODS and HOS).

Driver input is required to maintain an accurate record of a driver’sHOS. For instance, a driver must indicate when they are on duty whiledriving (i.e. on route to deliver inventory), or if they are drivingoff-duty (i.e. driving to lunch). Optionally, in step 5120, the localdevice will request driver status input every preset period of time. Forinstance, in a preferred embodiment, if the local device registers theengine is on for more than 1 hour then the device may request driververification that they are “on-duty” once every hour. At step 5122, thedriver status request is transmitted to display device. In step 5124,the status verification is displayed.

At step 5126, display device will receive status input, such as dutystatus. At step 5128, status input is then transmitted to local device5012. In step 5130, the local device records the input. At step 5132,the local device then updates the log with the driver status.

In another embodiment, where display device 5010 is not present in thesystem, the method used to enable advanced commercial motor vehiclefunctions may be similarly completed using a mobile device, such asclient device 110, in place of the display device. In this embodimentthe client device has cellular capabilities and is connected to thelocal device, as previously described.

Referring then to FIG. 51B, method 5101 for enabling ELD mode on a localdevice using client device 110 is described. At step 5051, the clientdevice receives an ELD mode selection. In a preferred embodiment, atthis step a unique identifier is used to connect the vehicle to a fleet,as previously described.

At step 5052, the ELD mode selection is transmitted to local device5012. In step 5053, the local device logs the request. At step 5054, therequest is transmitted to administrative server 5006. In a preferredembodiment, the request includes the CMV function selected in step 5051and the unique identifier associated with the device.

At step 5055, the request is processed by the administrative server. Ina preferred embodiment, this process includes reviewing account historyand processing payment through receipt of existing tokens, as previouslydescribed.

At step 5056, an approval is transmitted to client device 110. In step5057, the client device logs the request approval. In step 5058, theapproval is forwarded to the local device. At step 5059, an ELD modemodule on the local device is switched on. This module will monitor andlog vehicle data and driver data. In step 5060, the local device willrequest a data sync for the required vehicle data. At 5061, local deviceestablishes a data sync with vehicle device 5014 via a direct connectionthrough an OBD II port.

At step 5062, the vehicle device continuously generates data, such aspower status, motion, miles driven, and engine hours, through use. Atstep 5064, vehicle device 5014 will transmit the vehicle data to thelocal device. At step 5066, local device 5012 records the data. In step5068, the local device will generate and continuously update a log ofvehicle and driver data (i.e. RODS and HOS).

Optionally, in step 5070, the local device will request driver statusinput every preset period of time, as previously described. At step5072, the driver status request is transmitted to the client device. Instep 5074, the status verification is displayed.

At step 5076, the client device will receive status input, such as dutystatus. At step 5078, status input is then transmitted to local device5012. In step 5080, the local device records the input. At step 5082,the local device then updates the log with the driver status.

Referring then to FIG. 51C, third-party retrieval of vehicle data from alocal device is described as method 5102. This feature is importantbecause a FMCSA, or other agency, safety official may perform safetyaudits on an individual vehicle. To comply with FMCSA regulations, theELD device must have the ability to display and send vehicle and driverdata, such as HOS and RODs, during a safety audit.

At step 5133, display device 5010 will receive a data request. In apreferred embodiment, the display device will have different options ofELD data to display for a specified time frame, such as an HOS log, orROD. In step 5134, the data request is transmitted to local device 5012.

At step 5136, local device will generate a report. In a preferredembodiment, the report comprises the requested data over the specifiedtime period and is generated using the log of vehicle and driver data.In step 5137, the report is transmitted to the display device. At step5138, the report is displayed.

In a preferred embodiment, the application loaded on display device 5010will have a “share” feature to transmit the generated reports to anotherdevice wirelessly, such as through email, Bluetooth, or SMS messaging.In step 5139, the display device receives a selection to share thereport. At step 5140, the report is then transmitted to a third-partydevice, such as a FMCSA auditor’s mobile phone, or laptop.

Optionally, third-party device 5020 requests the data directly fromlocal device 5012. While the preferred method for establishing aconnection with the local device is via Bluetooth or Wi-Fi, aspreviously described, it should be appreciated that a direct wiredconnection could also be utilized via USB or ethernet.

At step 5142, the third-party device receives a request to establish aconnection with local device. In step 5143, a connection is established.At step 5144, the third-party device then receives a data request (i.e.for HOS or RODS). In step 5145, the request is transmitted to localdevice 5012.

At step 5146, the local device generates a report for the data requestedfrom the vehicle and driver data log. At step 5147, the local devicetransmits the report to the third-party device. At step 5148, the reportis recorded, logged and displayed on third-party device 5020.

Referring then to FIG. 51D, a preferred embodiment of a system forcommunication between a fleet manager device and a local device isdescribed as method 5103.

In step 5149, fleet manager device 5022 receives a request for access.Access is used to enable functionality. Access may be required toreceive detailed vehicle data, such as error codes or diagnostic troublecodes (DTC), carbon emissions, average MPG, average MPH and RODs or HOSor any other vehicle data available from the vehicle device. Eachrequest for access is serialized, and includes a status indicator, andis hashed and compressed, as previously described.

At step 5150, the access request is transmitted to administrative server5006. At step 5151, the administrative server approves and processes therequest. The processing may include a review of account history, requestaccuracy and receipt of funds from a bank via wire transfer or a creditcard transaction. Optionally, a payment through receipt of tokens may beused, as previously described.

At step 5152, approval is transmitted to the fleet manager device. Instep 5153, the approval is displayed on fleet manager device 5022.

In step 5154, fleet information is input into fleet manager device. In apreferred embodiment, this consists of vehicle and driver details foreach vehicle and driver in the motor carrier’s fleet. In one embodiment,local device 5012 is linked to a fleet, vehicle, and driver using aunique identifier for the local device, as previously described. In oneembodiment, the motor carrier is issued a unique identifier to be inputat the local device. The fleet manager would then provide additionaldetails regarding the devices linked. In step 5155, the fleet data istransmitted to administrative server 5006.

In step 5156, the administrative server will generate a fleet andfunction list. This list will include the vehicles with a local devicelinked to the fleet, drivers, and functions available. The functionsavailable are determined by the kind and number of tokens issued.Functions may include: displaying live vehicle data, displaying vehicleECU profiles, displaying logged vehicle data, and displaying a driver’sHOS or RODs. At step 5157, the list is transmitted to fleet managerdevice 5022. At step 5158, the list is displayed on the fleet managerdevice.

In step 5159, a data request is received by the fleet manager device. Inthis step the request may be for a specific driver’s HOS or RODs, orlocal device 5012 data, such as miles driven or PID error codes. In step5160, the data request is transmitted to the administrative server. Atstep 5161, the administrative server will verify the account has theappropriate tokens to fulfill the request. In this step, theadministrative server will also update the status of the token/s to“used”.

At step 5162, the data request is relayed to local device 5012. In step5163, the local device will filter the logged data for the datarequested. At step 5164, local device 5012 generates a report with therequested data. At step 5165, the report is transmitted toadministrative server 5006. In step 5166, the administrative serverforwards the report to fleet manager device 5022. At step 5167, thereport generated by the local device is displayed on the fleet managerdevice.

Optionally, the request is sent to the display device, or alternativelya client device, and then forwarded to the local device. At step 5084,the data request is relayed to display device 5010. In step 5086, thedisplay device forwards the request to the local device. At step 5088,the local device filters the logged data. At step 5090, local device5012 generates a report with the requested data. At step 5092, thereport is transmitted to the display device. In step 5094, the report issent to administrative server 5006. In step 5096, the administrativeserver forwards the report to fleet manager device 5022. At step 5098,the report generated by the local device is displayed on the fleetmanager device.

Referring then to FIG. 51E, communication between a technician deviceand a fleet vehicle device is described as method 5104. Thisfunctionality is important because a commercial motor carrier isresponsible for each vehicle’s compliance with state and federalregulations, such as carbon emissions regulations. This feature allows acommercial motor carrier to monitor fleet vehicles remotely and have thevehicles assessed and repaired by a remote technician device.

In one embodiment, payment may be requested which will allow passivemonitoring of a vehicle device. In this embodiment, when a vehicledevice produces an error or sensor fault, the DTC is sent to theadministrative server and then a notification is sent to the fleetmanager device. In an alternate embodiment, active monitoring isutilized. In this embodiment, tokens are used to determine a vehicledevice status at a particular time, then a fleet manager device receivesthe status, which may include a DTC. A preferred method of passivemonitoring is described below.

At step 5168, vehicle device 5014 generates an error. In step 5169, theDTC is transmitted to local device 5012. At step 5170, the local deviceupdates the log of vehicle data. At step 5171, the error is transmittedto administrative server 5006.

Optionally, in step 5030, local device transmits the error to displaydevice 5010. At step 5031, the error is then displayed. In step 5032,the error is transmitted to the administrative server.

At step 5174, the administrative server processes the notification. Atthis step, the administrative server may verify the account has therequired access clearance for passive monitoring and generate anotification. In step 5175, the error is transmitted to fleet managerdevice 5022. At step 5176, the error notification is displayed on thefleet manager device.

In a preferred embodiment the error notification comprises the DTC,identifying the error. Optionally, the error notification may alsoinclude a list of technicians. In one embodiment, at step 5177, atechnician may be requested from the list in the error notification. Inthis embodiment, a request for additional payment, for example bytokens, may be included in the tech request. The token request will beincluded if additional tokens are required to execute the tech request.The additional tokens may be required based on the account’s existingbalance, the type of error or service required, or tech requested.

At step 5178, a request for technician assistance or repair istransmitted to the administrative server. At step 5179, the server willprocess the request. At this step the server will determine if anyadditional tokens are requested or required, and then generate a technotification. At step 5180, the tech request notification is transmittedto technician device 5004. At step 5181, the request is displayed on thetechnician device.

Alternatively, the tech may not be selected from the error notification,or notified through the administrative server. In this alternateembodiment the technician may be selected from an alternate list andnotified through separate means. In either event, once a tech isnotified of the request, the tech must request access to the fleetvehicle devices.

In step 5182, technician device requests access to the fleet vehicle. Atstep 5183, the access request is transmitted to administrative server5006. In step 5184, the server processes the request. At step 5185, therequest is sent to the fleet manager device. At step 5186, the fleetmanager device receives a selection to approve or deny the technicianaccess. If a selection to deny is received, then a denial is returned tothe administrative server, and forwarded to the technician device. Ifapproved, then at step 5187, the approval is transmitted toadministrative server 5006.

At step 5188, administrative server will generate a vehicle functionlist. In a preferred embodiment, a vehicle function list will compriseoptions to request vehicle data, as well as options to performmaintenance and repair, such as ECU reprogramming as previouslydescribed. The available functions may be more or less expansivedepending upon available tokens. At step 5189, the vehicle functionslist is transmitted to technician device 5004. In step 5190, the vehiclefunctions list is displayed on the technician device.

At step 5191, the technician device receives a selection to requestvehicle data. At step 5192, the request is transmitted to theadministrative server. In step 5193, administrative server 5006 forwardsthe data request to the local device.

At step 5194, local device 5012 filers logged data for the datarequested. At this step, the local device may also determine to requestadditional data from vehicle device 5014. At step 5195, the local devicewill generate a response to the data request. At step 5196, the responseis transmitted to the administrative server.

Optionally, administrative server 5006 forwards the request generated instep5191 to display device 5010. In step 5033, administrative server5006 forwards the data request to the display device. At step 5034, thedisplay device forwards the request to local device 5012. At this step5035, the local device filters the logged data and may also determine torequest additional data from vehicle device 5014. At step 5036, thelocal device will generate a response to the data request. At step 5038,the response is transmitted to the display device. In step 5040, theresponse is forwarded to the administrative server.

At step 5197, the response is forwarded to the technician device. Atstep 5198, the requested data is displayed on the technician device. Theprocess may end here or proceed to ECU reprogramming, as previouslydescribed.

Although embodiments of the present disclosure have been described indetail, those skilled in the art should understand that they may makevarious changes, substitutions and alterations herein without departingfrom the spirit and scope of the present disclosure. Accordingly, allsuch changes, substitutions and alterations are intended to be includedwithin the scope of the present disclosure as defined in the followingclaims. In the claims, means-plus-function clauses are intended to coverthe structures described herein as performing the recited function andnot only structural equivalents, but also equivalent structures.

1. A system for making adjustments to an ECU connected to a network, thenetwork including a server, a client device, a local device, and avehicle device, the system comprising: a set of processors, in theserver, in the client device, in the local device and in the vehicledevice; a set of memories, each memory of the set of memories connectedto at least one processor of the set of processors; and the set ofmemories including a set of instructions that causes the system toperform the steps of: sending a first message to the vehicle device;receiving a response from the vehicle device to the first message withina time limit; masking a set of response parameters upon receipt of theresponse; retrieving a first configuration file and a set of PIDs fromthe vehicle device; and setting a power level associated with thevehicle device based on at least one of the first configuration file anda PID of the set of PIDs.
 2. The system of claim 1, wherein the set ofinstructions further causes the system to perform the steps of:receiving a SOTF map from the client device; reading the SOTF map; andchecking a vehicle data for one or more of a vehicle identifier, a partidentifier, and a serial number identifier.
 3. The system of claim 2wherein the set of instructions further causes the system to perform thesteps of: receiving the vehicle data from the client device; andproviding an error message when one or more of the vehicle identifier,the part identifier, and the serial number identifier is not in thevehicle data.
 4. The system of claim 3, wherein the set of instructionsfurther causes the system to perform the steps of: checking at least oneof an engine status, an ignition status, and a vehicle status; and ifthe vehicle status is normal then parsing the set of PIDs.
 5. The systemof claim 4, wherein the set of instructions further causes the system toperform the step of: generating a second configuration file including amodified CRC and an unmodified CRC.
 6. The system of claim 5, whereinthe set of instructions further causes the system to perform the stepsof: checking for a previous failure; performing a reflash recoveryoperation if the previous failure is indicated; and if the reflashrecovery operation is successful, then implementing the power levelbased on at least one of the first configuration file and the PID of theset of PIDs.
 7. The system of claim 6, wherein the set of instructionsfurther causes the system to perform the steps of: generating, at theclient device, an authorization to share a set of logged vehicle data;and sending the authorization to the local device.
 8. The system ofclaim 7, wherein the system further comprises a technician deviceconnected to the network, and wherein the set of instructions furthercauses the system to perform the step of: generating, at the localdevice, a logged data response from the set of logged vehicle data; andsending the logged data response to the technician device.
 9. The systemof claim 8, wherein the system further comprises a third party serverconnected to the network and wherein the set of instructions furthercauses the system to perform the step of: sending the logged dataresponse to the third party server.
 10. The system of claim 9, whereinthe set of instructions further causes the system to perform the stepsof: confirming presence of a data set indicating that the set of loggedvehicle data is one of certified or uncertified; and sending a messagebased on the indication.
 11. A system for making adjustments to an ECUconnected to a network, the network including a server, a client device,a local device, and a vehicle device, the system comprising: a set ofprocessors, in the server, in the client device, in the local device andin the vehicle device; a set of memories, each memory of the set ofmemories connected to at least one processor of the set of processors;and the set of memories including a set of instructions that causes thesystem to perform the steps of: sending a first message to the vehicledevice; receiving a response from the vehicle device to the firstmessage within a time limit; if the response is not received within thetime limit, then iteratively repeating the steps of: sending the firstmessage; and receiving the response from the vehicle device; until theresponse is received within the time limit; masking a set of responseparameters upon receipt of the response; providing the set of responseparameters includes a message header, a set of frame parameters, a valueof RPMs, a set of gear and transmission parameters, an ignition keyposition, a throttle position, and a coolant temperature; retrieving afirst configuration file and a set of PIDs from the vehicle device;reserving sufficient memory for performing tuning modifications;defining a PID of the set of PIDS for performing tuning modifications;and setting a power level associated with the vehicle device based on atleast one of the first configuration file and the PID of the set ofPIDs.
 12. The system of claim 11, wherein the set of instructionsfurther causes the system to perform the steps of: receiving a SOTF mapfrom the client device; reading the SOTF map; and checking a vehicledata for one or more of a vehicle identifier, a part identifier, and aserial number identifier.
 13. The system of claim 12 wherein the set ofinstructions further causes the system to perform the steps of:receiving the vehicle data from the client device; and providing anerror message when one or more of the vehicle identifier, the partidentifier, and the serial number identifier is not in the vehicle data.14. The system of claim 13, wherein the set of instructions furthercauses the system to perform the steps of: checking at least one of anengine status, an ignition status, and a vehicle status; and if thevehicle status is normal then parsing the set of PIDs.
 15. A method formaking adjustments to an ECU connected to a network, the networkincluding a server, a client device, a local device, and a vehicledevice, the method comprising: providing a set of processors, in theserver, in the client device, in the local device and in the vehicledevice; providing a set of memories, each memory of the set of memoriesconnected to at least one processor of the set of processors; andproviding a set of instructions, in the set of memories, that causes theset of processors to perform the steps of: sending a first message tothe vehicle device; receiving a response from the vehicle device to thefirst message within a time limit; if the response is not receivedwithin the time limit, then iteratively repeating the steps of: sendingthe first message; and receiving the response from the vehicle device;until the response is received within the time limit; masking a set ofresponse parameters upon receipt of the response; providing the set ofresponse parameters includes a message header, a set of frameparameters, a value of RPMs, a set of gear and transmission parameters,an ignition key position, a throttle position, and a coolanttemperature, retrieving a first configuration file and a set of PIDsfrom the vehicle device; reserving sufficient memory for performingtuning modifications; defining a PID of the set of PIDS for performingtuning modifications; and setting a power level associated with thevehicle device based on at least one of the first configuration file andthe PID of the set of PIDs.
 16. The method of claim 15, wherein the stepof providing the set of instructions further comprises providinginstructions that when executed cause the set of processors to carry outthe steps of: receiving a SOTF map from the client device; reading theSOTF map; and checking a vehicle data for one or more of a vehicleidentifier, a part identifier, and a serial number identifier.
 17. Themethod of claim 16, wherein the step of providing the set ofinstructions further comprises providing instructions that when executedcause the set of processors to carry out the steps of: receiving thevehicle data from the client device; providing an error message when oneor more of the vehicle identifier, the part identifier, and the serialnumber identifier is not in the vehicle data; and displaying the errormessage.
 18. The method of claim 17, wherein the step of providing theset of instructions further comprises providing instructions that whenexecuted cause the set of processors to carry out the steps of: checkingat least one of an engine status, an ignition status, and a vehiclestatus; and if the vehicle status is normal, then parsing the set ofPIDs.
 19. The method of claim 18, wherein the step of providing the setof instructions further comprises providing instructions that whenexecuted cause the set of processors to carry out the step of:generating a second configuration file including a modified CRC and anunmodified CRC.
 20. The method of claim 18, wherein the step ofproviding the set of instructions further comprises providinginstructions that when executed cause the set of processors to carry outthe step of: comparing a vehicle year to a predetermined year.